Стандарт IDEF1x Буханов С.А. bukhanov@yandex.ru Элементы реляционной модели Реляционная модель основана на математическом понятии отношения, физическим представлением которого является таблица. Реляционная база данных – это набор нормализованных отношений, которые различаются по именам. Реляционная база данных состоит из отношений, структура которых определяется с помощью особых методов, называемых нормализацией (normalization). Отношение Отношение – это плоская таблица, состоящая из столбцов и строк. Альтернативные названия - таблица, файл. В любой реляционной СУБД предполагается, что пользователь воспринимает базу данных как набор таблиц. Таблица, в которой все кортежи отличаются друг от друга, в математических терминах называется отношением. Атрибут Атрибут – это именованный столбец отношения. Альтернативные названия - столбец, поле В реляционной модели отношения используются для хранения информации об объектах, представленных в базе данных. Отношение обычно имеет вид двумерной таблицы, в которой строки соответствуют отдельным записям, а столбцы — атрибутам. При этом атрибуты могут располагаться в любом порядке - независимо от их переупорядочииания отношение будет оставаться одним и тем же, а потому иметь тот же смысл. Кортеж Кортеж – это строка отношения. Альтернативные названия - строка, запись Элементами отношения являются кортежи, или строки, таблицы. Кортежи могут располагаться в любом порядке, при этом отношение будет оставаться тем же самым, а значит, и иметь тот же смысл. Домен Домен – это набор допустимых значений одного или нескольких атрибутов. Домены представляют собой чрезвычайно мощный компонент реляционной модели. Каждый атрибут реляционной базы данных определяется на некотором домене. Домены могут отличаться для каждого из атрибутов, но два и более атрибутов могут определяться на одном и том же домене. Степень Степень отношения определяется количеством атрибутов, которое оно содержит. Отношение только с одним атрибутом имеет степень 1 и называется унарным (unary) отношением (или одноэлементным кортежем). Отношение с двумя атрибутами называется бинарным (binary), отношение с тремя атрибутами — тернарным (ternary), а для отношений с большим количеством атрибутов используется термин n-арное (n-агу). Определение степени отношения является частью заголовка отношения. Кардинальность Кардинальность – это количество кортежей, которое содержится в отношении. Количество содержащихся в отношении кортежей называется кардинальностью отношения. Эта характеристика меняется при каждом добавлении или удалении кортежей. Кардинальность является свойством тела отношения и определяется текущим состоянием отношения в произвольно взятый момент. Ключевые атрибуты Первичный ключ (primary key, PK) – минимальный набор атрибутов, уникально идентифицирующий кортеж в отношении. В правильно построенной реляционной базе данных в каждом отношении есть один или несколько атрибутов, значения в которых во всех кортежах разные – это атрибут (атрибуты) и называется первичным ключом отношения. Первичный ключ может представлять собой комбинацию атрибутов. Такой первичный ключ называется составным. Ключевые атрибуты Атрибут одного отношения, значения в котором совпадают со значениями атрибута, являющегося первичным ключом другого отношения, называется внешним ключом. Внешний ключ (Foreign key, FK), как и первичный ключ, тоже может представлять собой комбинацию атрибутов. На практике внешний ключ всегда будет составным (состоящим из нескольких атрибутов), если он ссылается на составной первичный ключ в другом отношении. Очевидно, что количество атрибутов и их типы данных в первичном и внешнем ключах совпадают. Если таблица связана с несколькими другими таблицами, она может иметь несколько внешних ключей. Внешние ключи являются неотъемлемой частью реляционной модели, поскольку реализуют отношения между таблицами базы данных. Логическое проектирование базы данных Логическое проектирование базы данных - процесс создания модели используемой информации на основе выбранной модели организации данных, но без учета типа целевой СУБД и других физических аспектов реализации. Логическое проектирование является вторым этапом проектирования базы данных, на котором происходит уточнение и преобразование концептуальной модели, созданной на предыдущем этапе, в логическую модель данных. Логическая модель данных создается на основе выбранной модели организации данных целевой СУБД (реляционная, сетевая, иерархическая или объектно-ориентированная), но этапе игнорирует все остальные характеристики выбранной СУБД, например, любые особенности физической организации ее структур хранения данных и построения индексов. Логическое проектирование базы данных Созданная логическая модель данных является источником информации для этапа физического проектирования и предоставляет разработчику физической модели данных средства проведения всестороннего анализа различных аспектов работы с данными, что имеет исключительно важное значение для выбора действительно эффективного проектного решения. Логическая модель данных играет также важную роль на этапе эксплуатации и сопровождения уже готовой системы. При правильно организованном сопровождении поддерживаемая в актуальном состоянии модель данных позволяет точно и наглядно представить любые вносимые в базу данных изменения, а также оценить их влияние на прикладные программы и использование данных, уже имеющихся в базе. Нормализация и нормальные формы Нормальная форма — свойство отношения в реляционной модели данных, характеризующее его с точки зрения избыточности, которая потенциально может привести к логически ошибочным результатам выборки или изменения данных. Нормальная форма определяется как совокупность требований, которым должно удовлетворять отношение. Процесс нормализации был впервые предложен Э. Ф. Коддом. Нормализация часто выполняется в виде последовательности тестов с целью проверки соответствия (или несоответствия) некоторого отношения требованиям заданной нормальной формы. Сначала были предложены только три вида нормальных форм: первая (1НФ), вторая (2НФ) и третья (ЗНФ). Затем Р. Бойсом и Э. Ф. Коддом было сформулировано более строгое определение третьей нормальной формы, которое получило название нормальной формы Бойса-Кодда (НФБК). Все эти нормальные формы основаны на функциональных зависимостях, существующих между атрибутами отношения, Нормальные формы более высокого порядка, которые превосходят НФБК, были введены позднее. К ним относятся четвертая (4НФ) и пятая (5НФ) нормальные формы. Но на практике эти нормальные формы более высоких порядков используются крайне редко. Нормализация и нормальные формы В теории реляционных баз данных обычно выделяется следующая последовательность нормальных форм: первая нормальная форма (1NF); вторая нормальная форма (2NF); третья нормальная форма (3NF); нормальная форма Бойса-Кодда (BCNF); четвертая нормальная форма (4NF); пятая нормальная форма, или нормальная форма проекциисоединения (5NF или PJ/NF). Основные свойства нормальных форм: каждая следующая нормальная форма в некотором смысле лучше предыдущей; при переходе к следующей нормальной форме свойства предыдущих нормальных свойств сохраняются. В основе процесса проектирования лежит метод нормализации, декомпозиция отношения, находящегося в предыдущей нормальной форме, в два или более отношения, удовлетворяющих требованиям следующей нормальной формы. Нормализация и нормальные формы Исходной точкой является представление предметной области в виде одного или нескольких отношений, и на каждом шаге проектирования производится некоторый набор схем отношений, обладающих лучшими свойствами. Процесс проектирования представляет собой процесс нормализации схем отношений, причем каждая следующая нормальная форма обладает свойствами лучшими, чем предыдущая. Каждой нормальной форме соответствует некоторый определенный набор ограничений, и отношение находится в некоторой нормальной форме, если удовлетворяет свойственному ей набору ограничений. Примером набора ограничений является ограничение первой нормальной формы - значения всех атрибутов отношения атомарны. Ненормализованная форма (ННФ) - таблица, содержащая одну или несколько повторяющихся групп данных. Функциональные и многозначные зависимости Нормальная форма представляет собой способ классификации таблицы на основе содержащихся в ней функциональных зависимостей (functional dependencies, FD). Функциональная зависимость означает, что, имея значение одного атрибута, можно всегда определить значение другого. В реляционной теории FD выражается стрелкой между двумя атрибутами. Например зависимость А —> В означает, что А определяет В. Зная номер сотрудника, можно определить его имя; зная шифр детали, можно указать ее вес и цвет, и т.д. Многозначная зависимость означает, что, имея значение одного атрибута, можно всегда определить множество значений другого атрибута. В реляционной теории она обозначается стрелкой с двумя остриями между двумя атрибутами. Например, зависимость А —>> В означает "А определяет много В". Зная имя преподавателя, можно получить список его студентов; зная шифр детали, можно определить шифры деталей, входящих в ее состав, и т.д. Первая нормальная форма (1НФ) Первая нормальная форма (1НФ) отношение, в котором на пересечении каждой строки и каждого столбца содержится одно и только одно значение. Для преобразования ненормализованной таблицы в первую нормальную форму (1НФ) в исходной таблице следует найти и устранить все повторяющиеся группы данных. Повторяющейся группой называется группа, состоящая из одного или нескольких атрибутов таблицы, в которой возможно наличие нескольких значений для единственного значения ключевого атрибута (атрибутов) таблицы. Первая нормальная форма (1НФ) Исходная, ненормализованная, таблица: Сотрудник Номер телефона Иванов И. И. 283-56-82 390-57-34 Петров П. Ю. 708-62-34 Первая нормальная форма (1НФ) Исходная, ненормализованная, таблица: Сотрудник Номер телефона Иванов И. И. 283-56-82 390-57-34 Петров П. Ю. 708-62-34 Таблица, приведённая к 1NF: Сотрудник Номер телефона Иванов И. И. 283-56-82 Иванов И. И. 390-57-34 Петров П. Ю. 708-62-34 Избыточность данных и аномалии Основная цель проектирования реляционной базы данных заключается в группировании атрибутов в отношения таким образом, чтобы минимизировать избыточность данных и тем самым сократить объем памяти, необходимый для физического хранения отношений, представленных в виде таблиц. Проблемы, связанные с избыточностью данных, можно проиллюстрировать, сравнив отношения Staff и Branch таблицах 1 и 2 с отношением StaffBranch таблице 3. Отношение StaffBranch является альтернативной формой представления отношений Staff и Branch. Упомянутые отношения описываются следующим образом: Staff (staffNo, sName, position, salary, branchNo) Branch (branchNo, bAddress) StaffBranch (staffNo, sName, position, salary, branchNo, bAddress) Обратите внимание, что здесь первичный ключ каждого отношения выделен жирным начертанием. Избыточность данных и аномалии В отношении Staff Branch содержатся избыточные данные, поскольку сведения об отделении компании повторяются в записях, относящихся к каждому сотруднику данного отделения. В противоположность этому в отношении Branch сведения об отделении содержатся только в одной строке, а в отношении Staff повторяется только номер отделения компании (branchNo), который представляет собой место работы каждого сотрудника. При работе с отношениями, содержащими избыточные данные, могут возникать проблемы, которые называются аномалиями обновления и подразделяются на аномалии вставки, удаления и модификации. Аномалии вставки Существуют два основных типа аномалий вставки, которые иллюстрируются с помощью отношения Staff Branch (см, таблицу 3). При вставке сведений о новых сотрудниках в отношение Staff Branch. необходимо указать и сведения об отделении компании, в котором эти сотрудники работают. Например, при вставке сведений о новом сотруднике отделения 'В007' требуется ввести сведения о самом отделении 'В007', которые должны соответствовать сведениям об этом же отделении в других строках отношения StaffBranch. Отношения, показанные в табл. 1 и 2, не подвержены влиянию этой потенциальной несовместимости данных, поскольку для каждого сотрудника в отношение Staff потребуется ввести только соответствующий номер отделения компании. Кроме того, сведения об отделении компании с номером 'BOO7' заносятся в базу данных однократно, в виде единственной строки отношения Branch. Аномалии вставки Для вставки сведений о новом отделении компании, которое еще не имеет собственных сотрудников, требуется присвоить значение NULL всем атрибутам описания персонала отношения StaffBranch, включая и табельный номер сотрудника staffNo. Но поскольку атрибут staffNo является первичным ключом отношения StaffBranch, то попытка ввести значение NULL в атрибут staffNo вызовет нарушение целостности сущностей и потому будет отклонена. Следовательно, в отношение StaffBranch невозможно ввести строку о новом отделении компании, содержащую значение NULL в атрибуте staffNo. Структура отношений, представленных в табл. 1 и 2, позволяет избежать возникновения этой проблемы, поскольку сведения об отделениях компании вводятся в отношение Branch независимости ввода сведений о сотрудниках. Сведения о сотрудниках, которые будут работать в новом отделении компании, могут быть введены в отношение Staff позже. Аномалии удаления При удалении из отношения Staff Branch строки с информацией о последнем сотруднике некоторого отделения компании сведения об этом отделении будут полностью удалены из базы данных. • Например, после удаления из отношения Staff Branch строки для сотрудника 'Mary Howe с табельным номером ' SA9' из базы данных неявно будут удалены все сведения об отделении с номером В007 . Однако структура отношений, показанных в табл. 1 и 2, позволяет избежать возникновения этой проблемы, поскольку строки со сведениями об отделениях компании хранятся отдельно от строк со сведениями о сотрудниках. Связывает эти два отношения только общий атрибут branchNo. При удалении из отношения Staff строки с номером сотрудника ' SA9' сведения об отделении 'ВО07' в отношении Branch останутся нетронутыми. Аномалии обновления При попытке изменения значения одного из атрибутов для некоторого отделения компании в отношении Staff Branch (например, адреса отделения 'ВООЗ') необходимо обновить соответствующие значения в строках для всех сотрудников этого отделения. Если такой модификации будут подвергнуты не все требуемые строки отношения Staff Branch., база данных будет содержать противоречивые сведения. • В частности, в нашем примере для отделения компании с номером 'ВООЗ' в строках, относящихся к разным сотрудникам, ошибочно могут быть указаны разные значения адреса этого отделения. Все приведенные выше примеры иллюстрируют то, что представленные в табл. 1 и 2 отношения Staff и Branch обладают более приемлемыми свойствами, чем отношение Staff Branch, представленное в табл. 3. Это доказывает, что отношение Staff Branch подвержено аномалиям обновления, но этих аномалий можно избежать путем декомпозиции первоначального отношения на отношения Staff и Branch. Вторая нормальная форма (2НФ) Полная функциональная зависимость: если А и B - атрибуты отношения, то атрибут B находится в полной функциональной зависимости от атрибута А, если атрибут B является функционально зависимым от А, но не зависит ни от одного собственного подмножества атрибута А. Функциональная зависимость А->B является полной функциональной зависимостью, если удаление какого-либо атрибута из А приводит к утрате этой зависимости. Функциональная зависимость А->В называется частичной, если в А есть некий атрибут, при удалении которого эта зависимость сохраняется. Вторая нормальная форма (2НФ) - отношение, которое находится в первой нормальной форме и каждый атрибут которого, не входящий в состав первичного ключа, характеризуется полной функциональной зависимостью от этого первичного ключа. Нормализация отношений 1НФ с приведением к форме 2НФ предусматривает устранение частичных зависимостей. Если в отношении между атрибутами существует частичная зависимость, то функционально-зависимые атрибуты удаляются из него и помещаются в новое отношение вместе с копией их детерминанта. Вторая нормальная форма (2НФ) Таблица находится во второй нормальной форме, если она находится в первой нормальной форме, и при этом любой ее атрибут, не входящий в состав первичного ключа, функционально полно зависит от первичного ключа. Функционально полная зависимость означает, что атрибут функционально зависит от всего первичного ключа, но при этом не находится в функциональной зависимости от какой-либо его части. Вторая нормальная форма (2НФ) Третья нормальная форма (ЗНФ) Транзитивная зависимость: если для атрибутов А, В и С некоторого отношения существуют зависимости вида А->B и B->C, это означает, что атрибут C транзитивно зависит от атрибута А через атрибут B (при условии, что атрибут А функционально не зависит ни от атрибута В, ни от атрибута С). Транзитивная зависимость является одним из типов функциональной зависимости. Третья нормальная форма (ЗНФ) - отношение, которое находится в первой и во второй нормальных формах и не имеет, не входящих в первичный ключ атрибутов, которые находились бы в транзитивной функциональной зависит от этого первичного ключа. Третья нормальная форма (ЗНФ) Нормализация отношений 2НФ с образованием отношений ЗНФ предусматривает устранение транзитивных зависимостей. Если в отношении существует транзитивная зависимость между атрибутами, то транзитивно зависимые атрибуты удаляются из него и помещаются в новое отношение вместе с копией их детерминанта. Фамили я Отде л Телефо н Гришин 1 11-22-33 Василье в 1 11-22-33 Петров 2 44-55-66 Фамили я Отде л Гришин 1 Василье в 1 Петров 2 Отде л Телефо н 1 11-22-33 2 44-55-66 Третья нормальная форма (ЗНФ) Начальник Наличие компьютера Должность Зарплата Гришин Кладовщик 20000 Нет Васильев Программис т 40000 Есть Васильев Кладовщик 25000 Нет Третья нормальная форма (ЗНФ) Начальник Наличие компьютера Должность Зарплата Гришин Кладовщик 20000 Васильев Программист 40000 Есть Васильев Кладовщик Нет Начальник 25000 Нет Должность Зарплата Гришин Кладовщик 20000 Васильев Программист 40000 Кладовщик Нет Васильев Кладовщик 25000 Программис т Есть Наличие компьютера Должность Модель сущность-связь В 1976 году Чен (Chen) предложил модель "сущностьсвязь" (Entity-Relationship model — ER- модель), которая в настоящее время стала самой распространенной технологией проектирования баз данных. IDEF1X IDEF1-методология создана компаниями Hugbes Aircraft и D-Appleton Сотрanу (DACOM). Она опирается как на собственные разработки обеих компаний, так и на реляционную теорию Т.Кодда и диаграммы "сущности-отношения" П.Ченна. В последнее десятилетие методология IDEF1 широко использовалась как аэрокосмическими, так и не аэрокосмическими компаниями. В 1983 г. в рамках программы ICAM ВВС США начали разработку проекта "Поддержка информационных интегрированных систем" (IISS). Целью этого проекта было создание технологии, позволяющей логически и физически объединить в сеть неоднородные компьютерные аппаратные и программные средства. IISS-подход заключался в создании и использовании единого семантического определения данных как ресурса, получившего название "Концептуальной схемы" и основанного на применении IDEF1-методологии моделирования. Мы рассматриваем расширенную версию IDEF1 (называемую IDEF1X). В ней учтены требования и опыт проекта IISS, а также практика ее применения в промышленности. Улучшение методологии заключается в повышении качества графического представления, развитии семантики и упрощении процедур разработки модели. Этот усовершенствованный вариант разработан и проверен компанией DACOM в процессе реализации военно-воздушных и частных проектов как совместно с ведущими аэрокосмическими корпорациями (General Dynamics, McDonnell Douglas, Rockwell International, General Electric), так и с неаэрокосмическими корпорациями (ARCO, Security Pacific National Bank, Sobering Plough). © 2002 ГОУ ―ГМЦ CALS-технологий‖ IDEF1X-подход IDEF1X - это методология семантического моделирования данных. Она разработана с учетом следующих требований: 1. Поддерживает разработку концептуальных схем Синтаксис IDEF1X поддерживает семантические конструкции, необходимые для разработки концептуальной схемы. Окончательная версия IDEFlX-модели обладает желаемыми характеристиками -непротиворечивостью, расширяемостью и адаптируемостью. 2. Обеспечивает ясный язык IDEF1X имеет простую, ясную, непротиворечивую структуру и четкие семантические понятия. Синтаксис и семантика IDEF1X сравнительно легки для понимания, хотя и являются достаточно мощным средством. 3. Проста для изучения Семантическое моделирование данных - новое понятие для многих пользователей IDEF1X. Проблема обучаемости этому языку является важным факторомом. Язык рассчитан на понимание и использование как профессиональными бизнесменами и системными аналитиками, так и администраторами данных и разработчиками баз данных. Он может служить эффективным средством коммуникации в коллективах, состоящих из различных специалистов. 4. Надежно проверена на практике IDEF1X базируется на многолетнем опыте предшествующих методологий и тщательно проверена как в проектах ВВС, так и в промышленности. 5. Возможность автоматизации IDEFlX-диаграммы могут создаваться большим числом графических программных пакетов. ВВС США на основе концептуальной схемы разработали активный трехсхемный словарь для построения прикладных программ и обработки запросов в распределенной неоднородной среде. Существует также коммерческое программное обеспечение, поддерживающее детализацию, анализ и управление конфигурацией IDEFlX-моделей. IDEF1X использует подход сущностей-отношений к семантическому моделированию данных. Исходная разработка IDEF1 заключалась в расширении понятий сущности-отношения по методу П.Ченна, объединенных с понятиями реляционной теории Т. Кодда. Кроме того, для улучшения графического представления и процедур моделирования IDEFlX-методология семантически обогащена введением отношений категоризации (называемых также отношениями обобщения). Язык IDEF1X включает коммерческие разработки D.Appleton Company и The Database Design Group. Основные конструкции IDEFlX-модели Основными конструкциями IDEFlX-модели являются: Предметы, к которым относятся данные, т.е. люди, места, идеи, события и т.д. Они изображаются блоками. Отношения между этими предметами, изображаемые соединяющими блоки линиями. Характеристики этих предметов, изображаемые именами атрибутов внутри блоков. Обзор Источники данных для информационной модели Уровни представления модели данных Логический уровень – отражает абстрактный взгляд на данные из предметной области. Объекты представляются именами из реального мира. Физический уровень - содержит строгое отображение структуры базы данных для конкретной СУБД. Элементы модели Основные элементы: сущности; атрибуты; связи. Ключевой атрибут Связь Сущность Мощность отношения Атрибут Дискриминатор Сущность Сущность: обозначает объект предметной области; представляет множество однотипных экземпляров объектов; Наименование сущности должно: однозначно отображать класс объектов предметной области; именоваться существительным в единственном числе; именуется по имени ее экземпляра. Имя сущности Сущность Сущность Сущность - набор предметов (людей, объектов, событий, дел, идей, имен и т.п.), обладающих одинаковым набором характеристик (атрибутов). Сущность получает в качестве наименования имя существительное или словосочетание, содержащее существительное в единственном числе. Подразделяются на: независимые; зависимые. Независимая сущность Зависимая сущность Атрибут Отличия между отдельными экземплярами сущностей отражаются значениями атрибутов. Атрибут – свойство сущности. Наименование атрибута должно: иметь четкое смысловое значение; быть существительным в именительном падеже единственного числа; быть уникальным в рамках модели. Сокращения разрешаются, однако, имя атрибута должно быть значимо и непротиворечиво для всей модели. Атрибут Атрибут мигрировавший Ключевые атрибуты Ключевой атрибут Ключевой атрибут Ключевой атрибут Связи Связи описывают отношения между сущностями. Отношение связи получает имя, выраженное глаголом или глагольным оборотом Имя сущности-родителя, имя отношения, мощность и имя сущностипотомка должны составлять имеющее смысл предложение. Для всех определенных отношений должно быть сформулировано название с точки зрения сущности-родителя (имя сущности-родителя в проверочном предложении стоит на первом месте). Иногда отношение связи может иметь два имени: с точки зрения сущности-родителя и с точки зрения сущности-потомка. Имя каждого отношения должно быть уникальным, хотя внутри одной модели имена могут повторяться Отдельный экземпляр отношения связывает отдельные экземпляры сущностей Типы связей идентифицирующие. неидентифицирующие. неспецифические (многие-ко-многим). Зависимые сущности Зависимость одной сущности от другой возникает при наличии между ними идентифицирующего отношения. Существование экземпляра зависимой сущности обусловлено существованием экземпляра родительской сущности. Зависимая сущность обозначается прямоугольником со скругленными углами. Ключевые атрибуты переносятся от родительской сущности к зависимой и помечаются (FK). Обязательность неидентифицирующих связей Необязательная связь Обязательная связь Мощность связей Мощность связи (Cardinality) – обозначает отношение числа экземпляров родительской сущности к числу экземпляров дочерней. Мощность отношения Типы мощности одному экземпляру родительской сущности соответствуют 0,1 или много экземпляров дочерней; одному экземпляру родительской сущности соответствуют 1 или много экземпляров дочерней; одному экземпляру родительской сущности соответствуют 0,1 экземпляр дочерней; одному экземпляру родительской сущности соответствуют точно заданное количество экземпляров дочерней; Категории Особый тип соединения сущностей. Родительская сущность описывает общие свойства сущностей категорий. Экземпляры родительской и дочерней сущностей представляют собой один и тот же реальный или абстрактный предмет. экземпляр сущности-категории одновременно является экземпляром общей сущности Дискриминатор неполного кластера Дискриминатор полного кластера Категории Ролевые имена (функциональные имена) Ролевое имя присваивается каждому появлению одного и того же атрибута в сущности: для различения каждого случая миграции а в сущности-потомке, когда атрибут мигрирует к сущности посредством более одного отношения, если экземпляр сущности имеет одно значения для одного случая появления атрибута и другое значение - для другого. Ролевое имя Унификация Атрибут приходит к дочерней сущности одновременно несколькими путями. В результате унификации отображается только одно вхождение ключа. Процесс построения Процесс носит итерационный характер Состоит из пяти стадий: Стадия Ноль. Стадия установления контекста. Стадия Один. Определяется набор сущностей. Стадия Два. Определяются отношения между сущностями. Стадия Три. Идентифицируются ключевые атрибуты. Стадия Четыре. Определяются неключевые атрибуты. Процесс построения Стадия Ноль. Стадия установления контекста. На этой стадии: • определяется область, охватываемая моделью • устанавливаются цели моделирования. Ранее составленная функциональная модель предметной области используется как основной источник информации. Отбираются соответствующие листы функциональной модели и использовать их при идентификации сущностей и атрибутов. Процесс построения Стадия Один. Определяется набор сущностей. Их состав будет пополняться и на следующих стадиях. Список сущностей формируется из всех имен существительных, представленных на листах функциональной модели . Особенно следует обратить внимание на словосочетания, содержащие слова «код», «номер», а также на все предметы, о которых имеется информация. ЗАКАЗЧИК ЗАКАЗ ПРОДУКТ Процесс построения Чтобы сократить список, необходимо по каждой возможной сущности из списка задать следующие вопросы: Можно ли описать данную сущность? (Обладает ли она набором характеристик?) Имеются ли у данной сущности экземпляры? Можно ли один экземпляр рассматриваемой сущности отличить от другого экземпляра этой же сущности? Относится ли она к чему-либо или описывает ли она что-либо? (Положительный ответ означает, что мы имеем дело не с сущностью, а с атрибутом) ЗАКАЗЧИК ЗАКАЗ ПРОДУКТ Процесс построения Стадия Два. Определяются отношения, существующие между сущностями, включенными в модель к данному моменту. Для облегчения работы составляется таблица отношений. В первой строке и первом столбце таблицы перечисляются все естественные сущности. Если между сущностями имеется какая-либо связь, на пересечении строки и столбца, соответствующих сущностям, ставится отметка. Таблица позволяет отследить все возможные отношения. Заказчик Заказчик Заказ Продукт Заказ на продукт Размещает Заказ Содержит Продукт Является частью Заказ на продукт Процесс построения ЗАКАЗЧИК ЗАКАЗЧИК размещает размещает ЗАКАЗ содержит / является частью ПРОДУКТ ПРОДУКТ ЗАКАЗ содержит является частью ЗАКАЗ-НА-ПРОДУКТ Процесс построения Стадия Три. Идентифицируются ключевые атрибуты для каждой из сущностей, включенных в модель к этому времени. Используются листы функциональной модели и список потенциальных сущностей. Процесс выбора начинается с тех сущностей, которые не являются сущностями-потомками в отношениях связи и категоризации. • Для каждой сущности составляется список из потенциальных ключей. • Подбираем все возможные атрибуты и группы атрибутов, которые могут однозначно идентифицировать экземпляры сущности. • В рамках модели отдельный атрибут может принадлежать только одной сущности. Другие сущности могут получить этот атрибут только в случае его миграции посредством отношения связи или категоризации. ЗАКАЗЧИК номер-заказчика размещает ПРОДУКТ ЗАКАЗ номер-заказчика (FK) содержит является частью ЗАКАЗ-НА-ПРОДУКТ Процесс построения Выбор ключевых атрибутов для сущностей-потомков и сущностей-категорий. Ключевой атрибут сущности-потомка состоит из: • мигрирующих атрибутов; • собственных атрибутов сущности; Ключевой атрибут сущности-категории полностью тождественен ключевому атрибуту общей сущности (допустимо вводить дополнительно только ролевые имена). ЗАКАЗЧИК номер-заказчика размещает ЗАКАЗ ПРОДУКТ номер-заказа номер-заказчика (FK) наименование-продукта содержит является частью ЗАКАЗ-НА-ПРОДУКТ номер-заказа (FK) наименование-продукта (FK) Процесс построения Стадия Четыре. Определяются, неключевые атрибуты и полностью определяется каждый из этих неключевых атрибутов. • Список ключевых атрибутов строится на основании составленного ранее списка потенциальных атрибутов. • Из списка выбираются не использованные ранее атрибуты. ЗАКАЗЧИК ЗАКАЗ номер-заказчика размещает номер-заказа имя-заказчика номер-заказчика (FK) адрес-заказчика дата-заказа телефон-заказчика содержит ПРОДУКТ наименование-продукта цена-продукта является частью ЗАКАЗ-НА-ПРОДУКТ номер-заказа (FK) наименование-продукта (FK) количество-продукта Резюме
