Моделирование информационных процессов и систем
реклама
Содержание Глава 1 Теоретические сведения ......................................................................... 2 1.1 Базы данных ................................................................................................. 2 1.2 Нормализация базы данных. ...................................................................... 3 1.3 Обеспечение непротиворечивости и целостности данных в базе. Типы взаимосвязей в модели. ..................................................................................... 5 Глава 2 Разработка информационной системы .................................................. 7 2.1 Создание таблиц и ввод исходных данных .............................................. 7 2.2 Схема данных ............................................................................................... 8 2.3 Основы работы с программным продуктом AllFusion ERwin Data Modeler .............................................................................................................. 10 2.4 Логический уровень модели данных ....................................................... 11 2.5 Физический уровень модели данных ...................................................... 14 2.6 Методика моделирования данных с помощью ERwin .......................... 15 2.7 Построение логической модели данных предметной области ............ 17 2.8 Построение физической модели данных. Генерация схемы базы данных............................................................................................................... 20 2.9 Расчет размера базы данных .................................................................... 25 2.10 Создание отчетов в пакете ERwin.......................................................... 27 2.11 ERwin. Прямое и обратное проектирование ......................................... 30 Глава 3 Задание на контрольную работу .......................................................... 36 Глава 4. Список тем для выполнения контрольной работы ........................... 37 Глава 1 Теоретические сведения 1.1 Базы данных Ба́за да́нных — представленная в объективной форме совокупность самостоятельных материалов (статей, расчётов, нормативных актов, судебных решений и иных подобных материалов), систематизированных таким образом, чтобы эти материалы могли быть найдены и обработаны с помощью электронной вычислительной машины (ЭВМ) База данных — совокупность данных, хранимых в соответствии со схемой данных, манипулирование которыми выполняют в соответствии с правилами средств моделирования данных. Классификация по модели данных: 1. 2. 3. 4. 5. 6. Иерархическая, Сетевая, Реляционная, Объектная и объектно-ориентированная, Объектно-реляционная, Функциональная. СУБД — Система Управления Базами Данных (DBMS — DataBase Management System). Программа, либо комплекс программ, предназначенных для полнофункциональной работы с данными. Как правило, включает в себя инструменты для создания и изменения структуры хранения наборов данных, а также средства доступа к хранимым данным, с возможностью их чтения, добавления, изменения и удаления. При этом, у большинства СУБД имеется собственный встроенный язык (возможно не один) для работы с данными. Сама база данных (БД) обычно находится просто в файлах закрытого, либо открытого формата. Реляционная (relational) БД отличается способом представления информации, находящейся в ней. Данные в такой базе хранятся в плоских таблицах. Каждая таблица имеет собственный, заранее определенный набор именованных колонок (полей). Поля таблицы обычно соответствуют атрибутам сущностей, которые необходимо хранить в базе. Количество строк (записей) в таблице неограниченно, и каждая запись соответствует отдельной сущности. Каждая таблица должна иметь первичный ключ (ПК) — поле или набор полей, содержимое которых однозначно определяет запись в таблице и отличает ее от других. Связь между двумя таблицами обычно образуется при добавлении в первую таблицу поля, содержащего значение первичного ключа второй таблицы. Реляционные СУБД (РСУБД) предоставляют средства для всевозможных пересечений и объединений любых таблиц, отбора записей по разнообразным условиям, группировки и сортировки результатов. Реляционная база данных сочетает наглядность представления информации с простотой (относительной) реализации своей концепции и является наиболее популярной структурой для хранения данных на сегодняшний день. 1.2 Нормализация базы данных. Нормализация таблиц базы данных - первый шаг на пути проектирования структуры реляционной базы данных. Строго говоря, конечно, не самый первый сначала надо решить, что же мы вообще будем хранить в базе, то есть определиться со структурой полей, их типами и размерностью, смыслом хранимой в них информации. Но это, как говорится, подразумевается по умолчанию:). Теория нормализации реляционных баз данных была разработана в конце 70-х годов 20 века. Согласно ей, выделяются шесть нормальных форм, пять из которых так и называются: первая, вторая, третья, четвертая, пятая нормальная форма, а также нормальная форма Бойса-Кодда, лежащая между третьей и четвертой. База данных считается нормализованной, если ее таблицы (по крайней мере, большинство таблиц) представлены как минимум в третьей нормальной форме. Часто многие таблицы нормализуются до четвертой нормальной формы, иногда, наоборот, производится денормализация. Использования таблиц в пятой нормальной форме (вернее сказать, сознательного приведения их к пятой нормальной форме) в реальных базах данных я лично не встречал. Главная цель нормализации базы данных - устранение избыточности и дублирования информации. В идеале при нормализации надо добиться, чтобы любое значение хранилось в базе в одном экземпляре, причем значение это не должно быть получено расчетным путем из других данных, хранящихся в базе. Первая нормальная форма Первая нормальная форма: запрещает повторяющиеся столбцы (содержащие одинаковую по смыслу информацию) запрещает множественные столбцы (содержащие значения типа списка и т.п.) требует определить первичный ключ для таблицы, то есть тот столбец или комбинацию столбцов, которые однозначно определяют каждую строку Вторая нормальная форма Вторая нормальная форма требует, чтобы неключевые столбцы таблиц зависили от первичного ключа в целом, но не от его части. Маленькая ремарочка: если таблица находится в первой нормальной форме и первичный ключ у нее состоит из одного столбца, то она автоматически находится и во второй нормальной форме. Третья нормальная форма Чтобы таблица находилась в третьей нормальной форме, необходимо, чтобы неключевые столбцы в ней не зависели от других неключевых столбцов, а зависели только от первичного ключа. Самая распространенная ситуация в данном контексте - это расчетные столбцы, значения которых можно получить путем каких-либо манипуляций с другими столбцами таблицы. Для приведения таблицы в третью нормальную форму такие столбцы из таблиц надо удалить. Нормальная форма Бойса-Кодда Нормальная форма Бойса-Кодда требует, чтобы в таблице был только один потенциальный первичный ключ. Чаще всего у таблиц, находящихся в третьей нормальной форме, так и бывает, но не всегда. Если обнаружился второй столбец (комбинация столбцов), позволяющий однозначно идентифицировать строку, то для приведения к нормальной форме Бойса-Кодда такие данные надо вынести в отдельную таблицу. Четвертая нормальная форма Для приведения таблицы, находящейся в нормальной форме Бойса-Кодда, к четвертой нормальной форме необходимо устранить имеющиеся в ней многозначные зависимости. То есть обеспечить, чтобы вставка / удаление любой строки таблицы не требовала бы вставки / удаления / модификации других строк этой же таблицы. Пятая нормальная форма Таблицу, находящуюся в четвертой нормальной форме и, казалось бы, уже нормализованную до предела, в некоторых случаях еще можно бывает разбить на три или более (но не на две!) таблиц, соединив которые, мы получим исходную таблицу. Получившиеся в результате такой, как правило, весьма искусственной, декомпозиции таблицы и называют находящимися в пятой нормальная форме. Формальное определение пятой нормальной формы таково: это форма, в которой устранены зависимости соединения. В большинстве случаев практической пользы от нормализации таблиц до пятой нормальной формы не наблюдается. Такая вот теория... Разработаны специальные формальные математические методы нормализации таблиц реляционных баз данных. На практике же толковый проектировщик баз данных, детально познакомившись с предметной областью, как правило, достаточно быстро набросает структуру, в которой большинство таблиц находятся в четвертой нормальной форме:). Краткие итоги. Зачем нужна нормализация. Главное, чего мы добьемся, проведя нормализацию базы данных - это устранение (или, по крайней мере, серьезное сокращение) избыточности, дублирования данных. Как следствие, значительно сокращается вероятность появления противоречивых данных, облегчается администрирование базы и обновление информации в ней, сокращается объем дискового пространства. Но не все так бело и пушисто. Зачастую, чтобы извлечь информацию из нормализованной базы данных, приходится конструировать очень сложные запросы, которые к тому же, бывает, работают довольно медленно - из-за, главным образом, большого количества соединений таблиц. Поэтому, чтобы увеличить скорость выборки данных и упростить программирование запросов, нередко приходится идти на выборочную денормализацию базы. 1.3 Обеспечение непротиворечивости и целостности данных в базе. Типы взаимосвязей в модели. На практике часто используются связи, устанавливающие различные виды соответствия между объектами «связанных» типов, — это один к одному (1:1), один ко многим (1:М), многие ко многим (М:М). Связь один к одному означает, что каждому экземпляру первого объекта (А) соответствует только один экземпляр второго объекта (В) и, наоборот, каждому экземпляру второго объекта (В) соответствует только один экземпляр первого объекта (А). Связь один ко многим означает, что каждому экземпляру одного объекта (А) может соответствовать несколько экземпляров другого объекта (В), а каждому экземпляру второго объекта (В) может соответствовать только один экземпляр первого объекта (А). Связь многие ко многим означает, что каждому экземпляру одного объекта (А) могут соответствовать несколько экземпляров второго объекта (В) и, наоборот, каждому экземпляру второго объекта (В) могут соответствовать тоже несколько экземпляров первого объекта (А). Пример 1.1. Рассмотрим совокупность следующих информационных объектов: СТУДЕНТ (Номер студента, ФИО, Дата рождения, Номер группы); СТИПЕНДИЯ (Номер студента, Размер стипендии); ГРУППА (Номер группы, Специальность); ПРЕПОДАВАТЕЛЬ (Код преподавателя, ФИО, Должность). Здесь информационные объекты СТУДЕНТ и СТИПЕНДИЯ связаны отношением один к одному, так как каждый студент может иметь только одну стипендию и каждая стипендия может быть назначена только одному студенту. Информационные объекты ГРУППА и СТУДЕНТ связаны отношением один ко многим, так как одна группа может включать в себя много студентов, в то время как каждый студент может обучаться только в одной группе. Информационные объекты СТУДЕНТ и ПРЕПОДАВАТЕЛЬ связаны отношением многие ко многим, так как один студент может обучаться у многих преподавателей и один преподаватель может обучать многих студентов. Для пользователей АИС важно, чтобы база данных отображала предметную область однозначно и непротиворечиво, т.е. чтобы она удовлетворяла условию целостности. Выделяют два основных типа ограничений по условию целостности данных в базе. 1. Каждая строка таблицы должна отличаться от остальных ее строк значением хотя бы одного столбца. Пример. Сотрудники одного отдела могут оказаться полными тезками, иметь одинаковые должность и телефон. 2. Внешний ключ не может быть указателем на несуществующую строку той таблицы, на которую он ссылается. Это ограничение называется ограничением целостности данных в базе по ссылкам. Глава 2 Разработка информационной системы 2.1 Создание таблиц и ввод исходных данных В Access используются три способа создания таблиц: путем ввода данных, с помощью Конструктора таблиц и с помощью Мастера создания таблиц. Для каждого из этих способов существует специальный ярлык новых объектов в списке таблиц. Если вы создали новый файл базы данных, то, кроме этих ярлыков, в списке таблиц больше ничего нет. Для создания новой таблицы нужно раскрыть список таблиц, щелкнув по ярлыку Таблицы на панели объектов окна базы данных, и затем нажать кнопку Создать. Тогда появится диалоговое окно Новая таблица, в котором вы и должны выбрать способ создания таблицы (рис. 1). Рис. 1 - Диалоговое окно Новая таблица Режим Конструктора дает больше всего возможностей при описании таблиц., поэтому рекомендуется использовать именно его. В режиме Конструктора таблицы создаются путем задания имен полей, их типов и свойств. Создание таблицу в режиме Конструктора выполняется следующим образом. Дважды щелкните левой кнопкой мыши на ярлыке Создание таблицы с помощью конструктора или нажмите на кнопку Создать в верхней части окна базы данных, выберите из списка в окне Новая таблица элемент Конструктор и нажмите кнопку ОК. В том и в другом случае откроется пустое окно Конструктора таблиц (рис. 2). Рис. 2. - Окно новой таблицы в режиме Конструктора В окне Конструктора таблиц в столбец Имя поля ввести имена полей создаваемой таблицы. В столбце Тип данных для каждого поля таблицы выбрать из раскрывающегося списка тип данных, которые будут содержаться в этом поле. В столбце Описание можно ввести описание данного поля. В нижней части окна Конструктора таблиц на вкладке Общие ввести свойства каждого поля или оставить значения свойств, установленные по умолчанию. На вкладке Подстановка можно настроить выбор значения поля из другой таблицы или запроса. После описания всех полей будущей таблицы необходимо выделить поля, составляющие первичный ключ, и нажать кнопку Ключевое поле. Далее следует нажать кнопку Сохранить. В окне Сохранить как в поле Имя таблицы ввести имя создаваемой таблицы и нажать кнопку ОК. После указанных действий в списке таблиц в окне базы данных появятся имя и значок новой таблицы. Ввести данные в созданную таблицу можно, открыв таблицу в режиме Таблицы. 2.2 Схема данных Создание схемы данных позволяет упростить конструирование многотаблиц, форм, запросов, отчетов, а также обеспечить поддержание целостности взаимосвязанных данных при корректировке таблиц. Схема данных наглядно отображает таблицы и связи между ними, а также обеспечивает использование связей при обработке данных и целостность БД. Схема данных задает структуру БД. Она является графическим образом БД. Схема данных базы графически отображается в своем окне, таблицы представлены списками полей, а связи - линиями между полями разных таблиц. Схема данных ориентирована на работу с таблицами, отвечающими требованиям нормализации, между которыми установлены связи 1:М и 1:1 с обеспечением целостности БД. Поэтому схема данных отроится в соответствии с информационно-логической моделью. При построении схемы данных Access автоматически определяет по выбранному полю связи тип связи между таблицами. Если поле, по которому нужно установить связь, является уникальным ключом, как в главной таблице, так и в подчиненной Access устанавливает связь «один – к – одному». Если поле связи является уникальным ключом в главной таблице, а в подчиненной таблице является неключевым или входит в составной ключ, Access устанавливает связь «один ко многим» от главной таблице к подчиненной. Связи - объединения. При выборе в качестве поля связи в главной таблице неключевого поля Access сообщает, что тип отношения не может быть определен. В этом случае между таблицами возможно установление только связи объединения. Связь - объединение обеспечивает объединение записей двух таблиц, имеющих одинаковые значения в поле связи. Причем производится объединение каждой записи из одной таблицы с каждой записью из другой таблицы при ус­ловии равенства значений в поле связи. Результатом объединения записей, который определяется выбором одного из трех способов, может быть: - объединение только тех записей, в которых связанные поля обеих таблиц совпадают; - объединение тех записей, в которых связанные поля обеих таблиц совпадают, а также объединение всех записей из первой таблицы, для которых нет связанных во второй, с пустой записью второй таблицы; - объединение тех записей, в которых связанные поля обеих таблиц совпадают, а также объединение всех записей из второй таблицы, для которых нет связанных в первой, с пустой записью первой таблицы. Создание схемы данных начинается в окне БД с выполнения команды Сервис / Схема данных или нажатием соответствующей кнопки. После этого можно выбрать таблицы, включаемые в схему данных, и приступить к определению связей между ними. Устанавливая связи между парой таблиц в схеме данных, надо выделить в главной таблице уникальное ключевое поле, по которому устанавливается связь, и протащить курсор мыши в соответствующее поле подчиненной таблицы. Поскольку схема строится для нормализованной БД, окне Связи автоматически установится тип отношения 1:М. в открывающемся Для такой связи можно задать параметр: Обеспечение целостности данных, а затем установить флажки Каскадное обновление связанных полей и Каскадное удаление связанных записей. Рис.3 – Схема данныхсозданная в СУБД MS Access 2.3 Основы работы с программным продуктом AllFusion ERwin Data Modeler CA ERwin Data Modeler (далее ERwin) - CASE-средство для проектирования и документирования баз данных, которое позволяет создавать, документировать и сопровождать базы данных, хранилища и витрины данных. Работа с программой начинается с создания новой модели, для которой нужно указать тип и целевую СУБД (рис.4). Рис.4 – Создание новой модели ERwin позволяет создавать логическую, физическую модели и модель, совмещающую логический и физический уровни. Логический уровень - это абстрактный взгляд на данные, на нем данные представляются так, как выглядят в реальном мире, и могут называться так, как они называются в реальном мире (например "Постоянный клиент", "Отдел" или "Заказ"). Объекты модели, представляемые на логическом уровне, называются сущностями и атрибутами. Логическая модель данных является универсальной и никак не связана с конкретной реализацией СУБД. Физический уровень зависит от конкретной СУБД. В физической модели содержится информация о всех объектах БД. Физическая модель зависит от конкретной реализации СУБД. Одной и той же логической модели могут соответствовать несколько разных физических моделей. На логическом уровне ERwin поддерживает две нотации (IE и IDEF1X), на физическом - три (IE, IDEF1X и DM). Далее будет рассматриваться работа с ERwin в нотации IDEF1X. Переключение между логической и физической моделями данных осуществляется через список выбора на стандартной панели (рис.2). Рисунок 5. – Переключение между уровнями Примечание. В созданной модели с настройками по умолчанию некорректно отображаются русские символы. Чтобы устранить этот недостаток, необходимо подкорректировать используемые в модели шрифты. Для этого необходимо зайти в меню Format -> Default Fonts & Colors, последовательно пройтись по всем вкладкам, в качестве шрифта выбрав любой шрифт, название которого заканчивается на CYR (например, Arial CYR), и выставив переключатель Apply To в значение All Objects. 2.4 Логический уровень модели данных Для создания на логическом уровне сущностей и связей между ними предназначена панель Toolbox: Рисунок 6. – Панель Toolbox Таблица 1. – Назначение кнопок панели Toolbox Вид кнопки Назначение кнопки Создание новой сущности. Для этого нужно щелкнуть по кнопке и затемпо свободному месту на модели Создание категории. Для установки категориальной связи нужно щелкнуть по кнопке, далее - по сущности-родителю, и затем - по сущности-потомку. Создание идентифицирующей связи. Для связывания двух сущностей нужно щелкнуть по кнопке, далее - по сущностиродителю, затем - по сущности-потомку. Создание связи "многие ко многим" Создание неидентифицирующей связи После создания сущности ей нужно задать атрибуты. Для этого нужно дважды щелкнуть по ней или в контекстном меню выбрать пункт Attributes (рис.7). Рис. 7 – Окно атрибутов выбранной сущности В появившемся окне можно просмотреть и отредактировать информацию о созданных атрибутах, создать новые. Здесь же задается первичный ключ. Для создания нового атрибута следует нажать кнопку New. В появившемся окне можно выбрать тип атрибута (BLOB, дата/время, число, строка), задать имя атрибута (Attribute Name) и имя столбца (Column Name), который будет соответствовать атрибуту на физическом уровне (рис.8). Рис. 8 – Окно создания атрибута После создания сущностей создаются связи между ними. При создании идентифицирующей связи атрибуты, составляющие первичный ключ сущностиродителя, мигрируют в состав первичного ключа сущности-потомка, при создании неидентифицирующей связи - просто в состав атрибутов сущностипотомка. Задать свойства связи или поменять ее тип можно дважды щелкнув по ней или выбрав в контекстном меню пункт Relationship Properties (рис. 6). Здесь во вкладке General можно задать имя связи (в направлении родитель-потомок и потомок-родитель), мощность связи (ноль, один или больше; один и больше (Р); ноль или один (Z); точно (конкретное число) ), поменять тип связи. Во вкладке RI Action можно задать ограничения целостности. Пример логической модели базы данных приведен на рис. 10. Рис. 9 – Окно свойств связи Рис.10 – Пример логической схемы БД 2.5 Физический уровень модели данных При переключении с логического уровня на физический автоматически будет создана физическая схема базы данных (рис.11) Рис.11 – Автоматически созданная физическая схема БД Ее можно дополнить, отредактировать или изменить. Принципы работы с физической схемой аналогичны принципам работы с логической схемой. По готовой физической схеме можно сгенерировать скрипты для выбранной СУБД. Для этого предназначен пункт меню Tools -> Forward Engineering/Schema Generation (рис.12). Рис. 12 – Окно генерации SQL-скриптов для целевой СУБД__ Здесь можно указать, какие именно скрипты следует генерировать, предварительно просмотреть их и непосредственно сгенерировать (при этом ERwin произведет подключение к целевой СУБД и в автоматическом режиме выполнит все SQL-скрипты). 2.6 Методика моделирования данных с помощью ERwin 1. Запустите CASE-средство: выберите Пуск | Программы | Computer Associates | AllFusion | Erwin Data Modeler | Erwin 2. Cтудент разрабатывает модель данных самостоятельно, поэтому для отказа от использования средства коллективной разработки моделей в окне ModelMart Connection Manager выберите Cancel. Система управления и хранения проектов ModelMart предоставляет репозитарий для коллективной разработки моделей. ModelMart гарантирует согласованность моделей, разграничение доступа к ним, поддержку версий и много других средств, которые так важны при командной разработке моделей. Сервер приложений для программных продуктов ModelMart поддерживает мощный набор инструментальных программных средств, обеспечивающих совместное (групповое) проектирование и разработку программных систем, включая механизмы объединения моделей и анализа изменений, контроль версий, возможность создания "компонент" модели и т.д. Для организации хранилища моделей в ModelMart используются СУБД на платформах Oracle, Sybase, Informix или SQL Server. 3. В окне Computer Associates Erwin выберите Cancel. 4. Установите шаблон модели: выберите File | New, выберите Logical / Physical, нажмите ОК. 5. Установите свойства элементов оформления: выберите Format | Default Fonts & Colors, выберите вкладку General, в списке Font выберите русский шрифт, например, Arial Cyr, в списке Size выберите 12, в области Apply to выберите All Objects, выберите вкладку Entities, в списке Font выберите русский шрифт, например, Arial Cyr, в области Name в списке Color выберите Синий, в области Definition в списке Font выберите русский шрифт, например, Arial Cyr, в области Box в списке Color выберите Желтый, в области Apply to выберите All Objects, выберите вкладку Attributes, в списке Font выберите русский шрифт, например, Arial Cyr, в области Foreign Key в списке Color выберите Красный, в области Apply to выберите All Objects, нажмите OK. 6. Установите логический уровень модели: выберите Model | флажком должна быть отмечена Logical Model. Логический уровень — это абстрактный взгляд на данные, когда данные представляются так, как выглядят в реальном мире, и могут называться так, как они называются в реальном мире, например "Постоянный клиент", "Отдел". Объекты модели, представляемые на логическом уровне, называются сущностями и атрибутами. Логическая модель данных может быть построена на основе другой логической модели, например на основе модели процессов. Логическая модель данных является универсальной и никак не связана с конкретной реализацией СУБД. 7. Выберите нотацию модели: выберите Model | Model Properties, выберите вкладку Notation, в области Logical Notation выберите IDEF1X, нажмите OK. Метод IDEFI основан на подходе Чена и позволяет построить модель данных, эквивалентную реляционной модели в третьей нормальной форме. На основе совершенствования метода IDEFI создана его новая версия — метод IDEFIX, разработанный с учетом таких требований, как простота для изучения и возможность автоматизации. IDEFIX-диаграммы используются в ряде распространенных CASE-средств. 8. Проверьте наличие на экране палитры инструментов Toolbox: выберите View | Toolbars, флажком должна быть отмечена Toolbox 9. Выберите режим просмотра соответствующий диаграмме ERD: нажмите кнопку Entity level на панели инструментов Toolbox. Диаграмма сущность-связь ( ERD ) представляет собой модель данных верхнего уровня. Она включает сущности и взаимосвязи, отражающие основные бизнес-правила предметной области. Такая диаграмма не слишком детализирована, в нее включаются основные сущности и связи между ними, которые удовлетворяют основным требованиям, предъявляемым к ИС. Диаграмма сущность-связь может включать связи "многие-ко-многим" и не включать описание ключей. Как правило, ERD используется для презентаций и обсуждения структуры данных с экспертами предметной области. 2.7 Построение логической модели данных предметной области В данном разделе необходимо построить в нотации IDEF1X в CASEсредстве ERwinDataModeler логическую схему данных предметной области, бизнес-процессы которой моделировались в предыдущих лабораторных работах. Примечание. При построении модели можно ограничиться 5-6 сущностями. IDEF1X IDEF1X основан на подходе Чена и позволяет построить модель данных, эквивалентную реляционной модели в третьей нормальной форме. Нотация Чена и сам процесс построения диаграмм сущность-связь изучалась в курсе "Организация баз данных и знаний", поэтому здесь мы рассмотрим только отличия IDFE1X от нотации Чена. Сущность (Entity) - реальный либо воображаемый объект, имеющий существенное значение для рассматриваемой предметной области. Каждая сущность должна иметь наименование, выраженное существительным в единственном числе. Каждая сущность должна обладать уникальным идентификатором. Каждый экземпляр сущности должен однозначно идентифицироваться и отличаться от всех других экземпляров данного типа сущности. Атрибут (Attribute) - любая характеристика сущности, значимая для рассматриваемой предметной области и предназначенная для квалификации, идентификации, классификации, количественной характеристики или выражения состояния сущности. Наименование атрибута должно быть выражено существительным в единственном числе. Связь (Relationship) - поименованная ассоциация между двумя сущностями, значимая для рассматриваемой предметной области. В методе IDEF1X все сущности делятся на зависимые и независимые от идентификаторов. Сущность является независимой от идентификаторов или просто независимой, если каждый экземпляр сущности может быть однозначно идентифицирован без определения его отношений с другими сущностями. Сущность называется зависимой от идентификаторов или просто зависимой, если однозначная идентификация экземпляра сущности зависит от его отношения к другой сущности. Независимая сущность изображается в виде обычного прямоугольника, зависимая - в виде прямоугольника с закругленными углами. В IDEF1X существуют следующие виды мощностей связей: N мощность - каждый экземпляр сущности-родителя может иметь ноль, один или более одного связанного с ним экземпляра сущности-потомка (по умолчанию); Р мощность - каждый экземпляр сущности-родителя должен иметь не менее одного связанного с ним экземпляра сущности-потомка; Z мощность - каждый экземпляр сущности-родителя должен иметь не более одного связанного с ним экземпляра сущности-потомка; конкретное число - каждый экземпляр сущности-родителя связан с некоторым фиксированным числом экземпляров сущности-потомка. Связь изображается линией, проводимой между сущностью-родителем и сущностью-потомком, с точкой на конце линии у сущности-потомка. По умолчанию мощность связи принимается равной N. Если экземпляр сущностипотомка однозначно определяется своей связью с сущностью-родителем, то связь называется идентифицирующей, в противном случае — неидентифицирующей. Идентифицирующая связь изображается сплошной линией, неидентифицирующая - пунктирной линией. В ERwin'е при установлении идентифицирующей связи атрибуты первичного ключа родительской сущности автоматически переносятся в состав первичного ключа дочерней сущности. Эта операция называется миграцией атрибутов. В дочерней сущности новые атрибуты помечаются как внешний ключ (FK). При установке неидентифицирующей связи атрибуты первичного ключа родительской сущности мигрируют в состав неключевых полей дочерней сущности. Построение логической модели данных предприятия по сборке и продаже компьютеров и ноутбуков. Построение модели данных начинается с выделения сущностей данной предметной области. В нашем случае были выделены следующие сущности: клиент - человек, который покупает компьютеры заказ - список компьютеров, которые покупает клиент компьютер комплектующие - то, из чего собирают компьютеры сотрудник - сотрудник предприятия, собирающий конкретный компьютер Далее рассмотрим связи между сущностями: Клиент - Заказ. Один клиент может делать несколько заказов. При этом если данные о клиенте имеются в базе данных, то он сделал минимум один заказ. Поэтому мощность связи - Р. Связь идентифицирующая, т.к. заказ без клиента существовать не может; Заказ - Компьютер. В рамках одного заказа клиент может заказать несколько компьютеров, но как минимум заказ должен состоять из одного компьютера. Поэтому мощность связи - Р. Связь идентифицирующая, т.к. компьютер без заказа существовать не может; Компьютер - Комплектующие. В состав одного компьютера входит много различных комплектующих; один и тот же тип комплектующего может входить в состав разных компьютеров. Мощность связи - много ко многим. В IDEF1X такой тип связи отсутствует, поэтому вводим промежуточную (ассоциативную) сущность - Конфигурация. Мощность связи между сущностями Компьютер и Конфигурация - Р, поскольку у любого компьютера должна быть конфигурация, мощность между сущностями Комплектующие и Конфигурация - N, поскольку какие-то комплектующие еще могут быть не установлены ни в один компьютер. Связь в обоих случаях идентифицирующая, т.к. конфигурация компьютера не может существовать без привязки к самому компьютеру и к комплектующим; Комплектующие - Тип комплектующих. Поскольку перечень типов комплектующих, которые могут быть установлены в компьютер, ограничен, но используется очень часто, то мы приняли решение создать еще одну сущность - Тип комплектующих. Мощность связи - Р. Связь идентифицирующая; Компьютер - Сотрудник. Каждый компьютер собирается каким-то одним сотрудником. Какие-то сотрудники могут собирать множество компьютеров. Мощность связи - N. Тип связи - неидентифицирующая, поскольку экземпляр сущности Компьютер уже может существовать, но за ним еще может быть не закреплен ни один сотрудник. Именно из этих же соображений в свойствах этой связи мы выбрали переключатель "NullsAllowed" (на диаграмме это отображается в виде незакрашенного ромбика со стороны сущности-родителя. Итоговая диаграмма показана на рис. 13: Рис.13 – Логическая модель данных предприятия по сборке компьютеров и ноутбуков Содержание отчета: 1. логическая модель данных предметной области 2. краткое описание каждой сущности 2.8 Построение физической модели данных. Генерация схемы базы данных Преобразовать созданную на предыдущем лабораторном занятии логическую модель данных в физическую модель для Oracle-8x. Сохранить полученный SQLскрипт в отчете. Теоретические сведения. Выбор сервера. Физическая модель содержит всю информацию, необходимую для реализации конкретной базы данных. Физический уровень представления модели зависит от выбранного сервера и является точным отображением системного каталога СУБД. ERwin поддерживает эту модель путем генерации ситемного каталога. Для выбора СУБД служит редактор Target Server (меню Server/Target Server…доступен только на физическом уровне). Диалог Target Server позволяет задать тип данных и опцию NULL для новых колонок. Тип данных можно выбрать в списке Default Datatype, который автоматически заполняется типами данных, поддерживаемых выбранным сервером. Группа кнопок Default Non-Key Null Option позволяет разрешить или запретить значения NULL для неключевых колонок. По умолчанию ERwin генерирует имена таблиц и колонок на основе имен соответствующих сущностей и атрибутов логической модели, с учетом ограничений, налагаемых выбранной СУБД. Значения по умолчанию можно при желании изменить путем изменения шаблона (Target Server – Table Name Macro) или вручную. Прямое и обратное проектирование. Процесс генерации физической схемы БД из логической модели данных называется прямым проектированием (Forward Engineering). При генерации физической схемы Erwin включает триггеры ссылочной целостности, хранимые процедуры, индексы, ограничения и другие возможности, доступные при определении таблиц в выбранной СУБД. Процесс генерации логической модели из физической БД называется обратным проектированием (Reverse Engineering). Erwin позволяет создать модель данных путем обратного проектирования имеющейся БД. После того, как модель создана, можно переключиться на другой сервер (модель будет конвертирована) и произвести прямое проектирование структуры БД для другой СУБД. Кроме режима прямого и обратного проектирования Erwin поддерживает синхронизацию между логической моделью и системным каталогом СУБД на протяжении всего жизненного цикла создания БД. Для генерации системного каталога БД следует выбрать пункт меню Tasks / Forward Engineering / Schema Generation. В окне Schema Generation в закладке Options можно задать опции генерации объектов БД – триггеров, таблиц, представлений, колонок, индексов и т.д. Кнопка Preview позволяет отобразить SQL–скрипт, создаваемый Erwin для генерации системного каталога СУБД. Нажатие кнопки Generate приведет к запуску процесса генерации схемы. Возникает диалог связи с БД, устанавливается сеанс связи с сервером и начинает выполняться SQL-скрипт. Кнопка Report сохраняет тот же скрипт в SQL текстовом файле. Эти команды можно в дальнейшем редактировать любым текстовым редактором и выполнять при помощи соответствующей утилиты сервера. Правила именования объектов в Oracle: Идентификатор: 1. может содержать до 30 символов (латинские буквы, цифры, символ подчеркивания, $, #); 2. начинается с буквы; 3. не чувствителен к регистру (eMp = EMP); 4. уникален в схеме пользователя; 5. отличен от зарезервированных слов. 6. Кроме того, название должно отражать смысл именуемого объекта (например, таблица STUD или STD). Имена атрибутов (колонок) должны содержать имя таблицы (STUD_ID или STD_NAME). Таблицы, колонки и представления при создании физической модели. Внесение новых таблиц и связей между ними на физическом уровне производятся также как на логическом уровне. Вызвать редакторы Table Editor или Column Editor для задания свойств таблиц и колонок можно через контекстнозависимое меню для этих таблиц. Все изменения, сделанные в Table Editor или Column Editor, не отражаются на именах сущностей и атрибутов, поскольку информация на логическом и физическом уровнях в Erwin хранится отдельно. Редактор Table Editor позволяет задать свойства любой таблицы модели, отличные от значения по умолчанию, в том числе имя таблицы, синонимы, правила валидации (утверждения), процедуры и т.д. Для задания свойств колонок, отличных от значения по умолчанию, служит редактор Column Editor. Он позволяет задать тип данных, опцию NULL, правила валидации и значение по умолчанию для каждой колонки. Правила валидации и значение по умолчанию должны быть описаны и именованы предварительно в Validation Rule Editor и Default / Initial Editor. Для вызова этих диалогов служат кнопки справа от соответствующих раскрывающихся списков. Представления (view) или иными словами временные или производные таблицы, представляют собой объекты БД, данные в которых не хранятся постоянно, как в таблице, а формируются динамически при обращении к представлению. Представление не может существовать само по себе, а определяется только в терминах одной или нескольких таблиц. Применение представлений позволяет разработчику БД обеспечить каждому пользователю или группе пользователей свой взгляд на данные, что решает проблемы простоты использования и безопасности данных. ERwin имеет специальные инструменты для создания и редактирования представлений. Палитра инструментов на физическом уровне содержит кнопки внесения представлений и установления связей между таблицами и представлениями. По умолчанию представление получает номер V_n, где n – уникальный порядковый номер представления. Для редактирования представления необходимо выбрать в контекстнозависимом меню для представления пункт View Editor. Каждой таблице можно задать необходимую информацию, которая будет использоваться в SQL-команде для создания представления. Правила валидации и значения по умолчанию. Правило валидации задает список допустимых значений для конкретной колонки и/или правила проверки допустимых значений. Значение по умолчанию – значение, которое нужно ввести в колонку, если никакое другое значение не задано явным образом во время ввода данных. С каждой колонкой или доменом можно связать значение по умолчанию (если выбранная СУБД поддерживает домены). В окне Validation Rule Editor можно задать максимальное и минимальное значение и тип валидации (где проверять – на сервере или в клиентском приложении). Например, значение, вводимое в колонку Age, должно быть больше 18, но меньше 180. Для описания этого правила можно создать правило валидации с именем «Проверка возраста», которое содержит выражение: Age BETWEEN 18 AND 180. СУБД выдаст сообщение об ошибке, если вводимый возраст находится вне границ диапазона. Редактор Valid Value позволяет создавать список всех допустимых значений, которые можно хранить в колонке, и связать его с правилом валидации. Редактор Default/Initial Editor позволяет создать значение, которое автоматически, по умолчанию, присваивается колонке. Например, дате приема сотрудника может быть присвоено значение по умолчанию «сегодняшнее число»,т.е. автоматически задается, что все новые сотрудники зачисляются в день ввода информации о них в БД. Индексы. В таблице БД данные обычно хранятся в том же порядке, в котором их ввели в таблицу. Многие реляционные СУБД имеют страничную организацию, при которой физически таблица может храниться фрагментарно в разных областях диска, причем строки таблицы располагаются на страницах неупорядоченно. Это позволяет быстро вводить данные, но осуществлять операцию поиска в системах, содержащих миллионы строк, приводит к катастрофическому падению производительности БД. Чтобы решить эту проблему СУБД использует особый объект, называемый индексом. Он подобен содержанию книги, которое указывает на все номера страниц, посвященных конкретной теме. Индекс содержит отсортированную по колонке или нескольким колонкам информацию и указывает на строки, в которых хранится конкретное значение колонки. При выполнении запроса СУБД просматривает индекс, вместо того, чтобы просматривать по порядку все строки таблицы. Поскольку значения в индексе хранятся в определенном порядке, просматривать нужно гораздо меньший объем данных, что значительно уменьшает время выполнения запроса. Индекс можно создать для всех колонок таблицы, по которым часто производится поиск. При генерации схемы физической БД Erwin автоматически создает отдельный индекс на основе первичного ключа каждой таблицы, а также на основе всех альтернативных ключей, внешних ключей, поскольку эти колонки наиболее часто используются для поиска данных. Для повышения производительности можно отказаться от генерации индексов по умолчанию и создать собственные индексы. Erwin автоматически генерирует имя индекса по принципу «Х» + имя ключа + имя таблицы (физическое!), где имя ключа «PK» для первичного ключа, «IFn» для внешнего, «AKn» - для альтернативного. В редакторе Index Editor можно изменить имя индекса изменить его определение так, чтобы он принимал уникальные или дублирующие значения, или изменить порядок сортировки данных. Триггеры и хранимые процедуры. Триггеры и хранимые процедуры – это именованные блоки кода SQL, которые заранее откомпилированы и хранятся на сервере для того, чтобы быстро призводить выполнение запросов, валидацию данных и выполнять другие часто вызываемые функции. Триггер – это процедура, которая выполняется автоматически как реакция на событие. Таким событием может быть вставка, изменение или удаление строки в существующей таблице. Триггер ссылочной целостности – это особый вид триггера, используемый для поддержания целостности между двумя таблицами, которые связаны между собой. Если строка в одной таблице вставляется, изменяется или удаляется, то триггер ссылочной целостности (RI-триггер) сообщает СУБД, что нужно делать с теми строками в других таблицах, у которых значение внешнего ключа совпадает со значением первичного ключа вставленной (измененной, удаленной) строки. По умолчанию Erwin генерирует триггеры, дублирующие декларативную ссылочную целостность. Для генерации триггеров Erwin использует механизм шаблонов – специальных скриптов, использующих макрокоманды. Шаблоны триггеров ссылочной целостности связываются с сущностями в зависимости от типа связи и роли сущности в этой связи. Они определяют, какое правило ссылочной целостности будет по умолчанию дополнено шаблоном триггера. Erwin имеет специальные редакторы, облегчающие создание и редактирование триггеров и процедур. Эти операции можно осуществить в окне Table Trigger Viewer пункта Trigger контекстно-зависимого меню для таблицы. Генерация скрипта. Для создания текста скрипта служат редакторы Table Template Editor и Schema Template Editor. Опция Generation Option позволяет задать тип скрипта – будет ли он выполнен до или после генерации таблицы или схемы. При создании текста скрипта так же, как и при создании текста хранимых процедур, может быть использован Erwin Template Toolbox. 2.9 Расчет размера базы данных ERwin позволяет рассчитать приблизительный размер базы данных в целом, а также таблиц, индексов и других объектов через определенный период времени после начала эксплуатации ИС. Для расчета размеров физических объектов служит диалог Volumetrics (рис. 1), который вызывается из меню Tools/Volumetrics. Редактор Volumetrics имеет 3 закладки - Settings, Report и Parameters. Settings. Служит для задания основных параметров, на основе которых вычисляется размер базы данных. В группе Table Row Counts для выделенной в левом списке Table таблицы задается начальное количество строк (Initial), максимальное количест­во строк (Мах) и прирост количества строк в месяц (Grow By). Если параметры Мах и Grow By используются одновременно, рост размера таблицы прекращается по достижении максимального размера. Те же самые параметры можно задать для каждой таблицы в закладке Volumetrics редактора Table Editor. Сразу после задания параметров Initial, Мах и Grow By в группе Sizing Estimates, расположенной в левом нижнем углу диалога, показывается средний размер строки, начальный размер таблицы и индексов. Таблица Column Properties позволяет задать свойства колонок таблицы. Имена колонок, их тип и размер (allocated) не редактируются. Можно изменять ширину поля Avg Width (для тех типов данных, для которых это допускается) и параметр Pct NULL (средний ожидаемый процент строк, в которых текущее поле принимает значение NULL). ERwin автоматически определяет в зависимости от выбранной СУБД, какие поля таблицы Column Properties могут изменяться. Группа Include Indexes позволяет учесть или игнорировать индексы, создаваемые на внешних (FK, Foreign Key), первичных (PK, Primary Key), альтернативных (AK, Alternate Key) ключах или инверсионных входах (IE, Inverse Entry) при расчете размера базы данных. Группа Storage позволяет задать объект физической памяти, в котором будет храниться выбранная таблица. Если объект физической памяти не описан, его можно определить в редакторе объекта физической памяти (вызывается кнопкой "•') Report. B ней отображаются результаты расчета размера базы данных (рис. 14). Группа Options позволяет выбрать тип объектов, по которым проводится расчет, Time - временной диапазон (начальное состояние или определенное время после начала эксплуатации). рис. 14 – диалог Volumetrics Результирующий отчет можно направить в диалог генерации отчетов Report Browser. Parameters. Служит для задания дополнительных параметров, используемых для расчета размера базы данных: TabIeFactor. Этот фактор показывает накладные расходы на хранение таблицы в базе данных. Например, значение TabIeFactor = 2 увеличит размер таблиц вдвое. IndexFactor показывает накладные расходы на хранение индекса в базе данных. Например, значение IndexFactor = 1 увеличит размер индекса с 1 до 1,5 Мбайт. RowOverhead используется для дополнительного пересчета количества байт каждой строки. Например, если значение RowOverhead = 10, размер каждой строки таблицы будет увеличен на 10 байт. BlobFactor и BlobBlockSize используются для пересчета Blob-колонок, хранящихся физически вне таблицы. BytesPerChar используется для задания количества байт, необходимых для хранения одного символа строкового типа. Для ASCII - это 1, для других кодировок значение может быть больше 1, например для UNICODE - 2. LogPercent используется для вычисления размеров log-файлов базы данных. LogPercent = 100 увеличивает базу данных вдвое. 2.10 Создание отчетов в пакете ERwin Для генерации отчетов в ERwin имеется эффективный и простой в использовании инструмент - Report Browser. Он позволяет выполнять предопределенные отчеты (объединенные по типам), сохранять результаты их выполнения, создавать собственные отчеты, печатать и экспортировать их в распространенные форматы. Каждый отчет может быть настроен индивидуально, данные в нем могут быть отсортированы и отфильтрованы. Диалог Report Browser вызывается кнопкой ERwin. в панели инструментов Диалог Report Browser имеет собственное меню и панель инструментов. Назначение кнопок панели инструментов показано в табл.5. Таблица 2. – Кнопки панели инструментов Report Browser кнопки назначение кнопок Создание нового отчета или папки Печать отчета Просмотр результата выполнения отчета Выполнение отчета Фиксация изменений (для редактируемого отчета) Поиск элементов отчета: задание условий поиска, поиск следующей строки и поиск другого отчета, соответствующего строке Включение и выключение дерева отчетов Показать список выполненных отчетов в хронологическом порядке Перейти к предыдущему отчету (при создании нового отчета на основе строки существующего) Выбор колонок и сортировка выполненного отчета Ассоциирование строки отчета с иконкой Сохранение выполненного отчета в виде представления В верхней левой части диалога расположено окно, отображающее дерево отчетов. Отчеты могут быть сгруппированы в папки. Каждый отчет может включать несколько результирующих наборов данных, каждое из которых генерируется при очередном выполнении отчета. Каждый элемент дерева помечен иконкой: - папка; - отчет; - редактируемый отчет; - результирующий набор данных; - представление. По умолчанию Report Browser содержит предварительно определенные отчеты, позволяющие наглядно представить информацию об основных объектах модели данных - как логической, так и физической. Для выполнения отчета достаточно дважды щелкнуть по нему в дереве отчетов или щелкнуть по соответствующей кнопке на панели инструментов. Результат выполнения отчета будет отображен в правом окне диалога Report Browser. Иконка результирующего набора будет также добавлена в дерево от-четов. В левом нижнем окне Report Browser отображается комментарий к отче-ту (вносится в диалоге ERwin Report Editor). В нижней части диалога содержится дополнительная панель инструментов для управления деревом отчетов (табл.6) Таблица 3. – Кнопки нижней панели инструментов Report Browser кнопки назначение кнопок Редактировать выделенный отчет Удалить отчет Показать только верхний уровень дерева Сделать выбранную папку корнем дерева (показать только выбранную ветку дерева) Сделать корнем дерева родительскую папку (по отношению к выбранной) Создание нового отчета Для создания нового отчета следует выбрать пункт меню File/New ERwin Report или щелкнуть по кнопке ERwin Report Editor. на панели инструментов. Появляется диалог В поле Name следует внести имя отчета. Категория отчета (Category) указывает на тип объектов модели, по которым будет создаваться отчет (атрибуты, сущности, домены, связи и т. д.). Закладки Definition и Note определения и комментария к отчету. служат соответственно для внесения Закладка Options отображает информацию, которая будет включена в отчет. В левой части закладки находится иерархический список категорий (Category). Папки в этом списке могут раскрываться и сворачиваться. Окно выбора позволяет включить соответствующий пункт списка в отчет. Иконка показывает, что соответствующую колонку в полученном отчете можно будет редактировать. Папка с символом позволяет выбрать условия фильтрации данных отчета, а с символом - условия сортировки. Кроме списка, закладка содержит следующие элементы управления: группу Options - позволяет выбрать режим отображения элементов в списке - показывать все возможные или только выбранные; Collapse All - сворачивает все папки списка; Clear All - отменяет все предварительно выбранные опции; Show Selected - раскрывает папки с выбранными опциями. После щелчка по кнопке ОК отчет будет добавлен в список отчетов диалога Report Browser. Для выполнения отчета нужно либо дважды щелк-нуть по его имени в списке, либо щелкнуть по кнопке в палитре инст-рументов. Существующий отчет, в том числе предопределенный, тоже можно изменить с помощью редактора, если в списке щелкнуть правой кнопкой мыши по имени отчета и выбрать во всплывающем меню пункт Edit ERwin Report. Полученный после выполнения отчета результирующий набор данных можно отформатировать, распечатать, экспортировать или сохранить в виде представления. Для форматирования результирующего набора данных следует в списке щелкнуть правой кнопкой мыши по имени набора и выбрать во всплывающем меню пункт Edit report format. В появляющемся диалоге Report Format можно изменить сортировку данных, очередность колонок, сделать колонку невидимой, задать ее стиль. Для редактирования результирующего набора данных следует в списке щелкнуть правой кнопкой мыши по имени набора и выбрать во всплывающем меню пункт Export result set. Допустимые форматы экспорта: CSV - текстовый файл; HTLM; DDE - экспорт в MS Word или MS Excel; RPTwin - экспорт в специализированный генератор отчетов. После форматирования и настройки результирующего набора данных его можно сохранить в качестве именованного представления. Использование представлений облегчает использование отчетов, поскольку все настройки достаточно сделать один раз. Каждый отчет может иметь несколько представлений. Для создания представления следует установить фокус в списке на нужный набор и щелкнуть по кнопке на панели инструментов. В диалоге Save View следует указать имя и определение представления. После щелчка по кнопке ОК представление добавится в список отчетов. 2.11 ERwin. Прямое и обратное проектирование Этап прямого проектирования в архитектуре «файл-сервер». Рассмотрим исходные логические и физические модели данных (Рис.15, Рис.16). Рис.15 – Логическая модель проектируемой ИС Рис.16 – Физическая модель проектируемой ИС Открываем физическую модель ИС и выбираем Access в качестве нужного типа СУБД, после чего типы данных в физической модели изменятся, так как по умолчанию она может быть настроена на другую СУБД. Создаем пустую базу данных в Access и подключаемся к ней (Рис.17, Рис.18). Рис.17 – Подключение к СУБД Access Рис.18 – Выбор БД Access Далее в меню выбираем Tools/ Forward Engineer/Shema Generation. В открывшемся окне на вкладке Options в пункте Index поставили галочки напротив пунктов Primary Key и Foreign Key, отвечающих за генерацию первичных и внешних ключей (Рис.19). Рис.19 – Установки по генерации схемы для базы данных Access После завершения операции по переносу физической модели в Access заходим в полученную базу данных и проверяем результат (Рис.20). Рис.20 – Схема данных в Access Этап обратного проектирования. В базе данных Access в таблице Адрес добавили поле e-mail и сохранили изменения. Далее зашли в Erwin и в меню выбрали Tools/ Reverse Engineer. В открывшемся окне выбрали тип новой модели - физическая, и СУБД из которой будем импортироваться физическая модель – Access (Рис.21). Рис.21 – Установки обратного проектирования Далее настраиваем параметры проектирования (Рис.22). Рис.22 – Установки по генерированию схемы для Erwin. Подключение к Access аналогично режиму прямого проектирования. Получаем физическую модель (Рис.23). Рис.23 – Физическая модель, полученная из БД Access Этап проектирования БД для архитектуры “клиент-сервер” В среде Erwin открыли физическую модель ИС, изменили тип СУБД на Microsoft SQL Server, в меню выбрали Tools/ Forward Engineer/Shema Generation. В открывшемся окне на вкладке Options в пункте Index поставили галочки напротив пунктов Primary Key и Foreign Key, отвечающих за генерацию первичных и внешних ключей. Нажали кнопку Preview (Рис.24). Рис.24 – Генерация SQL-кода для MS SQL Глава 3 Задание на контрольную работу Тема: Составление модели проектирования информационной системы. Цель: Освоение автоматизации функционального моделирования систем в программном продукте ERwin. Задачи: 1. Провести поиск информации по заданной теме. Проанализировать найденную информацию с точки зрения цели и темы работы. 2. Спроектировать модель информационной системы c помощью оболочки ERwin Data Modeler. Содержание отчета Отчет по контрольной работе сдается в печатном и электронном виде с титульным листом в срок, не позднее указанного по расписанию сдачи работы. Контрольная работа всеми студентами выполняется по одной тематике, но разным процессам. Электронную версию контрольной работы записать на диск и приложить сзади к отчету. Отчет должен содержать: 1. Введение, в котором отразить тему, цели и задачи работы. 2. Краткие теоретические сведения о проектировании информационных систем. 3. Описание общей методики функционального моделирования в системе ERwin. Краткие сведения о моделируемой ИС. 4. Физическую и логическую модель проектируемой ИС, SQL-код для MS SQL, схему данных в Access, не менее 3 отчетов по различным параметрам созданной ИС(поля без данных отображать не требуется), размер базы данных с исходными данными через 2 года. 5. Заключение. 6. Список литературы. Глава 4. Список тем для выполнения контрольной работы 1. Проектирование информационной системы контрольно-пропускного пункта 2. Проектирование информационной системы службы занятости 3. Проектирование информационной системы для автоматизации деятельности гостиницы 4. Проектирование автоматизированной информационной системы фирмы занимающейся производством корпусной мебели 5. Автоматизация деятельности туристической фирмы 6. Проектирование интернет магазина 7. Проектирование информационной системы для автоматизации деятельности библиотеки 8. Автоматизация судебного архива 9. Автоматизация кадрового учета на предприятии. 10. Автоматизация деятельности ресторана 11. Проектирование автоматизированной информационной системы типографии 12. Автоматизация деятельности библиотеки 13. Проектирование автоматизированной информационной системы фирмы занимающейся продажей компьютеров и комплектующих 14. Проектирование системы для автоматизации деятельности гипермаркета 15. Проектирование автоматизированного рабочего места специалиста по 16. управлению грузоперевозками 17. Проектирование новостного сайта 18. Проектирование информационной системы электронной библиотеки 19. Проектирование автоматизированной информационной системы фирмы занимающейся производством пластиковых окон 20. Проектирование информационной системы завода по производству автомобилей 21. Автоматизация деятельности автомобильного салона 22. Проектирование системы управления сайтом 23. Проектирование автоматизированной информационной системы учета медикаментов на складе 24. Проектирование web портала автомобильного салона 25. Авторизация деятельности завода 26. Индивидуальная тема согласовывается с преподавателем
