Методические рекомендации по выполнению лабораторных работ по курсу мдк. 01. 02 Методы и средства проектирования информационных систем для студентов специальности 09. 02. 04 «Информационные системы (по отраслям)»

Лабораторная работа №4 “Изучение объектов DFD-диаграмм” Диаграммы потоков данных (DFD, DataFlowDiagramming) используются для описания документооборота и обработки информации. Подобно IDEF0, DFD представляет модельную систему как сеть связанных между собой работ. Их можно использовать как дополнение к модели IDEF0 для более наглядного отображения текущих операций документооборота в корпоративных системах обработки информации. DFD описывает: функции обработки информации (работы, activities); документы (стрелки, arrows), объекты, сотрудников или отделы, которые участвуют в обработке информации; внешние ссылки (externalreferences), которые обеспечивают интерфейс с внешними объектами, находящимися за границами моделируемой системы; таблицы для хранения документов (хранилище данных, datastore). В BPwin для построения диаграмм потоков данных используется нотация Гейна-Сарсона. Для того чтобы дополнить модель IDEF0 диаграммой DFD, нужно в процессе декомпозиции в диалоге ActivityBoxCount надавить на радио-кнопку DFD. В палитре инструментов на новой диаграмме появляются кнопки: добавить в диаграмму внешнюю ссылку. Внешняя ссылка является источником или приемником данных извне модели; добавить в диаграмму хранилище данных. Хранилище данных позволяет описать данные, которые необходимо сохранить в памяти прежде, чем использовать в работах; ссылка на другую страницу. В отличие от IDEF0 инструмент off-pagereference позволяет направить стрелку на любую диаграмму (а не только на верхний уровень). В отличие от стрелок IDEF0, которые представляют собой жесткие взаимосвязи, стрелки DFD показывают, как объекты (включая данные) двигаются от одной работы к другой. Это представление потоков совместно с хранилищами данных и внешними сущностями делает модели DFD более похожими на физические характеристики системы – движение объектов (dataflow), хранение объектов (datastores), поставка и распространение объектов. В отличие от IDEF0, где система рассматривается как взаимосвязанные работы, DFD рассматривает систему как совокупность предметов. Контекстная диаграмма часто включает работы и внешние ссылки. Работы обычно именуются по названию системы, например “Система обработки информации”. Включение внешних ссылок в контекстную диаграмму не отменяет требования методологии четко определить цель, область и единую точку зрения на моделируемую систему. Работы. В DFD работы представляют собой функции системы, преобразующие входы в выходы. Хотя работы изображаются прямоугольниками со скругленными углами, смысл их совпадает со смыслом работ IDEF0. Внешние сущности. Изображают входы в систему и/или выходы из нее. Внешние сущности изображаются в виде прямоугольника с тенью и обычно располагаются по краям диаграммы. Одна внешняя сущность может быть использована многократно на одной или нескольких диаграммах. Обычно такой прием используют, чтобы не рисовать слишком длинных и запутанных стрелок. Стрелки (Потоки данных). Стрелки описывают движение объектов из одной части системы в другую. Поскольку в DFD каждая сторона работы не имеет четкого назначения, как в IDEF0, стрелки могут подходить и выходить из любой грани прямоугольника работы. В DFD также применяются двунаправленные стрелки для описания диалогов типа «команда-ответ» между работами, между работой и внешней сущностью и между внешними сущностями. Хранилище данных. В отличие от стрелок, описывающих объекты в движении, хранилища данных изображают объекты в покое. В материальных системах хранилища данных изображаются там, где объекты ожидают обработки, например, в очереди. В системах обработки информации хранилища данных являются механизмом, который позволяет сохранить данные для последующих процессов. Слияние и разветвление стрелок. В DFD стрелки могут сливаться и разветвляться, что позволяет описать декомпозицию стрелок. Каждый новый сегмент сливающейся или разветвляющейся стрелки может иметь собственное имя. Построение диаграмм DFD. Диаграммы DFD могут быть построены с использованием традиционного структурного анализа, подобно тому, как строятся диаграммы IDEF0. Сначала строится физическая модель, отображающая текущее состояние дел. Затем эта модель преобразуется в логическую модель, которая отображает требования к существующей системе. После этого строится модель, отображающая требования к будущей системе. И, наконец, строится физическая модель, на основе которой должна быть построена новая система. Альтернативным является подход, популярный при создании программного обеспечения, называемый событийным разделением, в котором различные диаграммы DFD выстраивают модель системы. Логическая модель строится как совокупность работ и документирования того, что эти работы должны делать. Модель окружения описывает систему как объект, взаимодействующий с событиями из внешних сущностей. Модель окружения обычно содержит описание цели системы, одну контекстную диаграмму и список событий. Контекстная диаграмма содержит один прямоугольник работы, изображающий систему в целом, и внешние сущности, с которыми система взаимодействует. Наконец, модель поведения показывает, как система обрабатывает события. Эта модель состоит из одной диаграммы, в которой каждый прямоугольник изображает каждое событие из модели окружения. Хранилища могут быть добавлены для моделирования данных, которые необходимо запоминать между событиями. Потоки добавляются для связи с другими элементами, и диаграмма проверяется с точки зрения соответствия модели окружения. Полученные диаграммы могут быть преобразованы с целью более наглядного представления системы, в частности, работы на диаграммах могут быть декомпозированы. Нумерация объектов. В DFD номер каждой работы может включать префикс, номер родительской работы (А) и номер объекта. Номер объекта – это уникальный номер работы на диаграмме. Например, работа может иметь номер А.12.4. Уникальный номер имеют хранилища данных и внешние сущности независимо от их расположения на диаграмме. Каждое хранилище данных имеет префикс D и уникальный номер, например D5. Каждая внешняя сущность имеет префикс Е и уникальный номер, например Е4. Задание. По заданному отделу построить диаграмму верхнего уровня взаимодействия отдела с внешними данными. Вопросы. Какие CASE-средства наиболее известны на российском рынке программного обеспечения? Каковы основные функции наиболее известного российского CASE-средства функционального моделирования? В чем особенности CASE-средства RationalRose? В чем особенности DFD-диаграмм, что в них описывается? В чем особенности объектов DFD-диаграмм? В чем различия функциональной, логической, физической моделей, а также моделей окружения и поведения? Лабораторная работа №5 “Изучение основных функций пакета ERwin. Создание логической модели” ERwin – средство концептуального моделирования БД, использующее методологию IDEF1X. ERwin реализует проектирование схемы БД, генерацию ее описания на языке целевой СУБД (ORACLE, Informix, Ingres, Sybase, DB/2, Microsoft SQL Server, Progress и др.) и реинжиниринг существующей БД. ERwin выпускается в нескольких различных конфигурациях, ориентированных на наиболее распространенные средства разработки приложений 4GL. Версия ERwin/OPEN полностью совместима со средствами разработки приложений PowerBuilder и SQLWindows и позволяет экспортировать описание спроектированной БД непосредственно в репозитории данных средств. Для ряда средств разработки приложений (PowerBuilder, SQLWindows, Delphi, VisualBasic) выполняется генерация форм и прототипов приложений. Сетевая версия ERwinModelMart обеспечивает согласованное проектирование БД и приложений в рабочей группе. Основные получаемые преимущества: существенное повышение скорости разработки за счет мощного редактора диаграмм, автоматической генерации базы данных, автоматической подготовки документации; нет необходимости ручной подготовки SQL-предложений для создания базы данных; возможность легко вносить изменения в модель при разработке и расширении системы; возможность автоматической подготовки отчетов по базе данных; важно, что эти отчеты всегда в точности соответствуют реальной структуре БД; разработчики прикладного программного обеспечения снабжены удобными в работе диаграммами; тесная интеграция со средствами 4GL позволяет уже на стадии информационного моделирования задавать отображение данных в приложениях; обратное проектирование позволяет документировать и вносить изменения в существующие информационные системы; поддержка однопользовательских СУБД позволяет использовать для персональных систем современные технологии, что значительно упрощает переход от настольных систем к системам в технологии клиент-сервер (upsizing). Построение моделей в ERwin Возможны две точки зрения на информационную модель и, соответственно, два уровня модели. Первый – логический уровень (точка зрения пользователя)означает прямое отображение фактов из реальной жизни. Например, люди, столы, отделы, собаки и компьютеры являются реальными объектами. Они именуются на естественном языке, с любыми разделителями слов (пробелы, запятые и т.д.). На физическом уровне модели рассматривается использование конкретной СУБД, определяются типы данных (например, целое или вещественное число), индексы для таблиц. ERwin предоставляет возможности создавать и управлять этими двумя различными уровнями представления одной диаграммы (модели), равно как и иметь много вариантов отображения на каждом уровне. Термин “логический уровень” в ERwin соответствует концептуальной модели. Этапы построения информационной модели: определение сущностей; определение зависимостей между сущностями; задание первичных и альтернативных ключей; определение атрибутов сущностей; приведение модели к требуемому уровню нормальной формы; переход к физическому описанию модели: назначение соответствий имя сущности – имя таблицы, атрибут сущности – атрибут таблицы; задание триггеров, процедур и ограничений; генерация базы данных. Erwin создает визуальное представление (модель данных) для решаемой задачи. Это представление может использоваться для детального анализа, уточнения и распространения документации, необходимой в цикле разработки. Однако ERwin далеко не только инструмент для рисования. ERwin автоматически создает базу данных (таблицы, индексы, хранимые процедуры, триггеры для обеспечения ссылочной целостности и другие объекты, необходимые для управления данными). Создание сущности Для внесения сущности в модель необходимо щелкнуть по кнопке сущности на панели инструментов (ErwinToolbox) , затем – по тому месту на диаграмме, где необходимо расположить новую сущность. Щелкнув правой кнопкой мыши по сущности и выбрав из всплывающего меню пункт EntityEditor, можно вызвать диалог EntityEditor, в котором определяются имя, описание и комментарии сущности. Каждая сущность должна быть полностью определена с помощью текстового описания в закладке Definition. Эти определения полезны как на логическом уровне, поскольку позволяют понять, что это за объект, так и на физическом уровне, поскольку их можно экспортировать как часть схемы и использовать в реальной БД (CREATECOMMENTonentity_name). Закладки Note, Note2, Note3, UDP (UserDefinedProperties – Свойства, определенные пользователем) служат для внесения дополнительных комментариев и определений к сущности. В закладке Icon каждой сущности можно поставить в соответствие изображение, которое будет отображаться в режиме просмотра модели на уровне иконок и изображение, которое будет отображаться на всех других уровнях. Закладка UDP диалога EntityEditor служит для определения свойств, определяемых пользователем (User – DefinedProperties). При нажатии на кнопку этой закладки вызывается диалог User – DefinedPropertyEditor (также вызывается из меню Edit/UDPs). В нем необходимо указать вид объекта, для которого заводится UDP (диаграмма в целом, сущность, атрибут и т.д.) и тип данных. Для внесения нового свойства следует щелкнуть в таблице по кнопке и внести имя, тип данных, значение по умолчанию и определение. Создание атрибутов Для описания атрибутов следует, щелкнув правой кнопкой по сущности, выбрать в появившемся меню пункт AttributeEditor. Появится диалог AttributeEditor. Если щелкнуть по кнопке New, то в появившемся диалоге NewAttribute можно указать имя атрибута, имя соответствующей ему в физической модели колонки и домен. Домен атрибута будет использоваться при определении типа колонки на уровне физической модели. Для атрибутов первичного ключа в закладке General диалога AttributeEditor необходимо сделать пометку в окне выбора PrimaryKey. Закладки Definition, Note и UDP несут те же функции, что и при определении сущности, но на уровне атрибутов. Для большей наглядности диаграммы каждый атрибут можно связать с иконкой. Это можно сделать при помощи списка выбора Icon в закладке General. Очень важно дать атрибуту правильное имя. Атрибуты должны именоваться в единственном числе и иметь четкое смысловое значение. Согласно синтаксису IDEF1X, имя атрибута должно быть уникальным в рамках модели (а не только в рамках сущности!). По умолчанию при попытке внесения уже существующего имени атрибута ERwin переименовывает его. Например, если атрибут Комментарий уже существует в модели, другой атрибут (в другой сущности) будет назван Комментарий/2, затем Комментарий/3 и т.д. При переносе атрибутов внутри и между сущностями можно воспользоваться техникой drag&drop, выбрав кнопку в палитре инструментов. Создание связи Для создания новой связи следует выбрать идентифицирующую или неидентифицирующую связь в палитре инструментов (ERwinToolbox), щелкнуть сначала по родительской, а затем по дочерней сущности. В палитре инструментов кнопка соответствует идентифицирующей связи, кнопка связи многие-ко-многим и кнопка соответствует неидентифицирующей связи. Для редактирования свойств связи следует щелкнуть правой кнопкой мыши по связи и выбрать на контекстном меню пункт RelationshipEditor. В закладке General появившегося диалога можно задать мощность, имя и тип связи. Мощность связи (Cardinality) – служит для обозначения отношения числа экземпляров родительской сущности к числу экземпляров дочерней. Различают четыре типа мощности: общий случай, когда одному экземпляру родительской сущности соответствуют 0, 1 или много экземпляров дочерней сущности, не помечается каким-либо символом; символом P помечается случай, когда одному экземпляру родительской сущности соответствуют 1 или много экземпляров дочерней сущности (исключено нулевое значение); символом Z помечается случай, когда одному экземпляру родительской сущности соответствуют 0 или 1 экземпляр дочерней сущности (исключены множественные значения); цифрой помечается случай, когда одному экземпляру родительской сущности соответствует заранее заданное число экземпляров дочерней сущности. По умолчанию символ, обозначающий мощность связи, не показывается на диаграмме. Для отображения имени следует в контекстном меню, которое появляется, если щелкнуть правой кнопкой мыши по любому месту диаграммы, не занятому объектами модели, выбрать пункт DisplayOptions/Relationship и затем включить опцию Cardinality. Тип связи (идентифицирующая/неидентифицирующая). В IDEF1X различают зависимые и независимые сущности. Тип сущности определяется ее связью с другими сущностями. Идентифицирующая связь устанавливается между независимой (родительский конец связи) и зависимой (дочерний конец связи) сущностями. Когда рисуется идентифицирующая связь, ERwin автоматически преобразует дочернюю связь в зависимую. Зависимая сущность изображается прямоугольником со скругленными углами. Экземпляр зависимой сущности определяется только через отношение к родительской сущности. При установлении идентифицирующей связи атрибуты первичного ключа родительской сущности автоматически переносятся в состав первичного ключа дочерней сущности. Эта операция дополнения атрибутов дочерней сущности при создании связи называется миграцией атрибутов. В дочерней сущности новые атрибуты помечаются как внешние ключи – (FK). При установлении неидентифицирующей связи дочерняя сущность остается независимой, а атрибуты первичного ключа родительской сущности мигрируют в состав неключевых компонентов дочерней. Неидентифицирующая связь служит для связи независимых сущностей. Идентифицирующая связь показывается на диаграмме сплошной линией с жирной точкой на дочернем конце связи, неидентифицирующая – пунктирной. Для неидентифицирующей связи можно указать обязательность (Nulls в закладке General диалога RelationshipEditor). В случае обязательной связи (NoNulls) при генерации схемы БД атрибут внешнего ключа получит признак NOTNULL, несмотря на то, что внешний ключ не войдет в состав первичного ключа дочерней сущности. В случае необязательной связи (NullsAllowed) внешний ключ может принимать значение NULL. Необязательная неидентифицирующая связь помечается прозрачным ромбом со стороны родительской сущности Имя связи (VerbPhrase) – фраза, характеризующая отношение между родительской и дочерней сущностями. Для связи один-ко-многим идентифицирующей или неидентифицирующей достаточно указать имя, характеризующей отношение от родительской к дочерней сущности (Parent-to-Child). Для связи многие-ко-многим следует указывать имена как Parent-to-Child, так и Child-to-Parent. Для отображения имени следует в контекстном меню, которое появляется, если щелкнуть правой кнопкой мыши по любому месту диаграммы, не занятому объектами модели, выбрать пункт DisplayOptions/Relationship и затем включить опцию VerbPhrase. Имя роли или функциональное имя (Rolename) – это синоним атрибута внешнего ключа, который показывает, какую роль играет атрибут в дочерней сущности. Задать имя роли можно в закладке Rolename/RIActions диалога RelationshipEditor. Рис.8. Имена ролей внешних ключей В примере, приведенном на рис.8, в сущности Сотрудник внешний ключ Номер отдела имеет имя роли «Где работает», которое показывает, какую роль играет этот атрибут в сущности. По умолчанию в списке атрибутов показывается только имя роли. Для отображения полного имени атрибута (как функционального имени, так и имени роли) следует в контекстном меню, которое появляется, если щелкнуть правой кнопкой мыши по любому месту диаграммы, не занятому объектами модели, выбрать пункт DisplayOptions/Entities и затем включить опцию Rolename/Attribute. Полное имя показывается как функциональное имя и базовое имя, разделенные точкой (рис.8). Обязательным является применение имен ролей в том случае, когда два или более атрибутов одной сущности определены по одной и той же области, т.е. они имеют одну и ту же область значений, но разный смысл. Рис.9. Случай обязательности имен ролей На рис.9 сущность Продажа валюты содержит информацию об акте обмена валюты, в котором участвуют две валюты – проданная и купленная. Информация о валютах содержится в сущности Валюта. Следовательно, сущности Продажа валюты и Валюта должны быть связаны дважды, и первичный ключ – Номер валюты должен дважды мигрировать в сущность Валюта в качестве внешнего ключа. Необходимо различать эти атрибуты, которые содержат информацию о номере проданной и купленной валюты (имеют разный смысл), но ссылаются на одну и ту же сущность Валюта (имеют общую область значений). В примере на рис.9 атрибуты получили имена ролей Проданная и Купленная. Другим примером обязательного применения имен ролей являются рекурсивные связи, когда одна и та же сущность является и родительской и дочерней одновременно. Правила ссылочной целостности (ReferentialIntegrity (RI)) – логические конструкции, которые выражают бизнес–правила использования данных и представляют собой правила вставки, замены и удаления. Задать правила ссылочной целостности можно в закладке Rolename/RIActions диалога RelationshipEditor. При генерации схемы БД на основе опций логической модели будут сгенерированы правила декларативной ссылочной целостности, которые должны быть предписаны для каждой связи, и триггеры, обеспечивающие ссылочную целостность. Рис.10. Миграция имен ролей На рис.10 существует идентифицирующая связь между сущностями Команда и Игрок. Что будет, если удалить команду? Экземпляр сущности Игрок не может существовать без команды (атрибут первичного ключа В какой команде играет. Номер команды не может принимать значение NULL), следовательно, нужно либо запретить удаление команды, пока в ней числится хотя бы один игрок, либо удалять вместе с командой и всех ее игроков. Такие правила удаления (ParentDelete) называются ParentRestrict (ограничение) и ParentCascade (каскад). Сущности Игрок и Гол, в свою очередь, тоже связаны идентифицирующей связью и, если на удаление игрока наложено правило каскадного удаления всех записей о его голах, то при удалении команды будут удалены все игроки команды и все голы, забитые этими игроками. Связь многие-ко-многим возможна только на уровне логической модели данных. Такая связь обозначается сплошной линией с двумя точками на концах. Для внесения связи следует сначала нажать на кнопку в палитре инструментов (ERwinToolbox), а затем по очереди щелкнуть по обеим связанным сущностям. Связь многие-ко-многим должна именоваться (VerbPhrase) двумя фразами – в обе стороны. Это облегчает чтение диаграммы. Создание ключей Каждый экземпляр сущности должен быть уникален. Первичный ключ (primarykey) – это атрибут или группа атрибутов, однозначно идентифицирующие экземпляр сущности. Атрибуты первичного ключа на диаграмме не требуют специального обозначения – это те атрибуты, которые находятся в списке атрибутов выше горизонтальной линии. При внесении нового атрибута в диалоге AttributeEditor для того, чтобы сделать его атрибутом первичного ключа, нужно включить флажок PrimaryKey в нижней части закладки General. На диаграмме ключевой атрибут можно внести в состав первичного ключа, воспользовавшись режимом переноса атрибутов (кнопка в палитре инструментов). В одной сущности может оказаться несколько атрибутов или наборов атрибутов, претендующих на роль первичного ключа. Такие претенденты называются потенциальными ключами (candidatekey). Ключи могут быть сложными, т.е. содержащими несколько атрибутов. Сложные первичные ключи не требуют специального обозначения – это список атрибутов выше горизонтальной линии. При выборе первичного ключа предпочтение должно отдаваться более простым ключам, т.е. ключам, содержащим меньшее количество атрибутов. Многие сущности имеют только один потенциальный ключ. Такой ключ становится первичным. Некоторые сущности могут иметь более одного возможного ключа. Тогда один из них становится первичным, а остальные – альтернативными ключами. Альтернативный ключ (AlternativeKey) – это потенциальный ключ, не ставший первичным. Каждому ключу соответствует индекс, имя которого также присваивается автоматически. Имена ключа и индекса при желании можно изменить вручную. На диаграмме атрибуты альтернативных ключей обозначаются как (Akn.m.), где n – порядковый номер ключа, m – порядковый номер атрибута в ключе. Рис.11. Сущность «Сотрудник» с отображением ключей Внешние ключи (ForeignKey) создаются автоматически, когда связь соединяет сущности: связи образуют ссылку на атрибуты первичного ключа в дочерней сущности и эти атрибуты образуют внешний ключ в дочерней сущности (миграция ключа). Атрибуты внешнего ключа обозначаются символом (FK) после своего имени (рис.11). Атрибут внешнего ключа Где работает.Номер отдела (“Где работает” – имя роли) сущности Сотрудник является атрибутом первичного ключа (PK) в сущности Отдел. Зависимая сущность может иметь один и тот же ключ из нескольких родительских сущностей. Сущность может также получить один и тот же внешний ключ несколько раз от одного и того же родителя через несколько разных связей. Когда ERwin обнаруживает одно из этих событий, он распознает, что два атрибута одинаковы, и помещает атрибуты внешнего ключа в зависимой сущности только один раз. Это называется унификацией. Есть случаи, когда унификация нежелательна. Например, когда два атрибута имеют одинаковые имена, но на самом деле они отличаются по смыслу. В этом случае необходимо использовать имена ролей внешнего ключа (рис.9). Домены Домен можно определить как совокупность значений, из которых берутся значения атрибутов. Каждый атрибут может быть определен только на одном домене, но на каждом домене может быть определено множество атрибутов. В понятие домена входит не только тип данных, но и область значений данных. Например, домен “Возраст” можно определить как положительное целое число и определить атрибут Возраст сотрудника как принадлежащий этому домену. В ERwin домен может быть определен только один раз и использоваться как в логической, так и в физической модели. На логическом уровне домены можно описать без конкретных физических свойств. На физическом уровне они получают специфические свойства, которые можно изменить вручную. Так, домен “Возраст” может иметь на логическом уровне тип Number, на физическом уровне домену будет присвоен тип INTEGER. Для создания домена в логической модели служит диалог DomainDictionaryEditor. Его можно вызвать из меню Edit/DomainDictionary. Для создания нового домена в диалоге DomainDictionaryEditor следует: щелкнуть по кнопке New. Появляется диалог NewDomain; выбрать родительский домен из списка DomainParent. Новый домен можно создать на основе уже созданного пользователем домена, либо на основе изначально существующего. По умолчанию ERwin имеет четыре предопределенных доменов (String, Number, Blob, Datetime). Новый домен наследует все свойства родительского домена. Эти свойства в дальнейшем можно переопределить; набрать имя домена в поле LogicalName. Можно также указать имя домена на физическом уровне в поле PhysicalName. Если физическое имя не указано, по умолчанию оно принимает значение логического имени; щелкнуть по кнопке OK; В диалоге DomainDictionaryEditor можно связать домен с иконкой, с которой он будет отображаться в списке доменов (DomainIcon), иконкой, с которой атрибут, определенный на домене будет отображаться в модели (IconInheritedbyAttribute). Каждый домен может быть описан в закладке Definition, снабжен комментарием в закладке Note или свойством определенным пользователем в закладке UDP. ERwin имеет специальный инструмент, который значительно облегчает создание новых атрибутов в модели, используя описание доменов, - IndependentAttributeBrowser. Этот диалог вызывается (и скрывается) по горячему ключу CTRL+B. С его помощью можно выбрать в списке домен и по методу drag&drop перенести его в какую-либо сущность. В ней будет создан новый атрибут с именем, которое следует задать в окне NameInheritedbyAttribute диалога DomainDictionaryEditor. Если значение поля не задано, по умолчанию принимается имя домена. На физическом уровне диалог DomainDictionaryEditor позволяет редактировать физические свойства домена. Имя этой закладки зависит от выбранного сервера БД. На ней можно задать конкретный тип данных, соответствующих домену, правила присвоения NULL – значений, правила валидации (правила проверки допустимых значений) и задания значения по умолчанию. Правила валидации и значения по умолчанию должны быть предварительно описаны и именованы. Для вызова диалогов редактирования правил валидации и значений по умолчанию служат кнопки справа от соответствующего списка выбора (Valid и Default). Функции других закладок диалога DomainDictionaryEditor: General. Задание родительского домена (DomainParent) и имени, присваиваемого колонке при ее создании с помощью IndependentColumnBrowser. С помощью опции PhisicalOnly домен можно определить только на уровне физической модели. Comment. Внесение комментария к атрибуту. UDP. Свойства, определяемые пользователем. VisualBasic – PowerBuilder. Задание специальных свойств домена для кодогенерации клиентского приложения. Задание. На основе ранее созданной функциональной модели и описания заданного отдела создать логическую модель с использованием пакета ERwin. Вопросы. Каково назначение пакета ERwin и его основные функции? В чем состоят главные преимущества пакета ERwin? Опишите этапы построения информационной модели. Из каких элементов состоит диаграмма "сущность-связь"? Опишите характеристики связей в методологии IDEF1X. Какие типы ключей используются в пакете ERwin, каково их назначение? Каково предназначение доменов, приведите примеры доменов различного вида.

Похожие:

	Методические рекомендации по выполнению практических работ по междисциплинарному... Мдк. 01. 01 раздел 3 Технические средства информатизации разработаны на основе Федерального государственного образовательного стандарта...		Методические рекомендации по выполнению практических занятий и лабораторных... Методические рекомендации предназначены для проведения практических и лабораторных занятий по мдк 01. 02
	Методические указания по выполнению практической (лабораторной) работы... ...		Методические рекомендации по выполнению лабораторных и практических... Методические рекомендации по выполнению лабораторных и практических работ для студентов 2-го курса
	Методические указания составлены на кафедре «Автоматика и системотехника» Проектирование информационных систем: Методические указания к выполнению практического задания №5 для студентов специальности 071900...		Методические указания составлены на кафедре «Автоматика и системотехника» Проектирование информационных систем: Методические указания к выполнению практического задания №6 для студентов специальности 071900...
	Методические рекомендации по выполнению лабораторных работ по мдк...		Пояснительная записка Данная рабочая тетрадь предназначена для студентов... Огсэ. 03 Английский язык для студентов, обучающихся по специальности 230401 «Информационные системы» (по отраслям)
	Методические указания по выполнению лабораторной работы №13 для студентов... Установка web-интерфейса к серверу Mysql в Linux. Методические указания по выполнению лабораторной работы №13 для студентов специальности...		Методические указания для студентов по выполнению лабораторных и... Методические указания для студентов по выполнению лабораторных и практических работ
	Методические рекомендации для студентов по выполнению практических... Методические рекомендации предназначены для студентов гаоу спо ткстп г. Тольятти, обучающихся по специальности 260807 «Технология...		Методические рекомендации по выполнению контрольных работ для студентов... Методические рекомендации по выполнению контрольных работ для студентов заочного отделения
	Методическое пособие по выполнению лабораторных работ по дисциплине... Изыскания и основы проектирования, автомобильных дорог. Методическое пособие по выполнению лабораторных работ по дисциплине «Основы...		Методические указания по выполнению практических работ для студентов... Мдк. 05. 04 Механизация и электроснабжение горных работ, электропривод и автоматизация горных машин и комплексов
	Методические указания по выполнению лабораторных работ по дисциплине “Базы данных” Методические указания предназначены для студентов специальностей 230401 «Прикладная математика», 230105 «Программное обеспечение...		Методические указания по выполнению практических и лабораторных работ... Учебно-методическое пособие предназначенодля студентов 3 курса, обучающихся по профессии 23. 01. 03 Автомеханик. Пособие содержит...