task_18912x

Тема контрольной: Учёт междугородних переговоров
Тематика контрольной работы по дисциплине направлена на проектирование
базы данных с помощью инструментальных средств для выбранной
предметной области.
Основные разделы контрольной работы
I. Описание предметной области
1. Формулировка целей построения базы данных.
2. Определение реализуемых базой данных функций
a. Перечень бизнес-процессов, выполняемых в рамках
заданной функции
b. Формы документов, используемых при выполнении
бизнес-процессов в рамках заданной функции
c. Определение
групп
пользователей,
реализующих
заданную функцию.
3. Описание объектов данных, используемых в бизнес-процессе
a. Наименование объекта, краткая характеристика
b. Описание свойств объектов, участвующих в бизнеспроцессе.
 наименование свойства
 маска ввода
4. Описание отношений, выявленных между объектами предметной
области
a. наименование отношения между объектами, краткая
характеристика
b. Свойства отношений
5. Формулировка
ограничений
целостности,
оказывающих
существенное влияние на реализацию заданных функций
6. Требования к безопасности данных
Полученную информацию необходимо структурировать и представить в виде
схем, таблиц и рисунков.
II. Построение концептуальной модели данных (модель «сущностьсвязь»)
1. Выбор и описание локальных представлений
2. Описание всех структурных элементов ER-модели:
a. Сущности: описание, наименование, характеристики
участия сущности в связях
b. Атрибуты: описание, наименование, роль, тип данных
(для логической модели), ключи (группы)
c. Связи: описание, наименование, тип, свойства связи,
типы ссылочной целостности
3. Объединение локальных представлений в глобальную модель
предметной области
III. Построение нормализованной (до 3 НФ) реляционной модели
предметной области
IV. Построение физической модели БД, т.е. схемы базы данных
использованием CASE-средств
с
Автоматизированное создание баз данных с использованием CASEсредств
CASE-технология – совокупность методов проектирования
информационных систем, а также набор инструментальных средств,
позволяющих моделировать предметную область, анализировать модель на
всех стадиях разработки и сопровождения системы, разрабатывать
приложения.
Под CASE-средством понимается программное средство,
поддерживающее процессы жизненного цикла информационной системы:
анализ требований, проектирование прикладного программного обеспечения
и БД, генерацию кода, тестирование, документирование, обеспечение
качества, управление конфигурацией и управление проектом.
На каждом этапе жизненного цикла используется определенная группа
CASE-средств. К одной из них относятся средства проектирования БД,
обеспечивающие логическое моделирование данных и автоматическую
генерацию схем БД на уровне программного кода. Эти действия
выполняются с помощью программных продуктов: ERwin (Computer
Associates), ER/Studio (Embarcadero Technologies, Inc), Designer 2000 (Oracle),
Silverrun (Computer Systems Advisers) и др.
Рассматриваемые CASE-средства имеют два уровня представления
модели данных – логический и физический. Логический уровень – это
абстрактный взгляд на данные. Объекты модели на логическом уровне
называются сущностями и атрибутами. Логическая модель данных является
универсальной и не связана с конкретной СУБД. Физическая модель данных
содержит информацию обо всех объектах БД. Поскольку стандартов на
объекты БД не существует, физическая модель зависит от конкретной СУБД.
Одной логической модели могут соответствовать несколько разных
физических моделей. Если в логической модели не имеет значения, какой тип
данных имеет атрибут, то в физической модели важно описать всю
информацию о физических объектах – таблицах, индексах и т.д.
Вначале проектировщик создает логическую модель в виде ERдиаграммы в определенной нотации (например, IDEF1X). После этого он
выбирает СУБД и CASE-средство автоматически создает физическую
модель. На основе физической модели CASE-средства могут сгенерировать
системный каталог СУБД или соответствующий SQL-скрипт (сценарий
создания БД).
Этот процесс называется прямым проектированием. Создав
логическую модель, можно сгенерировать физические модели под любые
поддерживаемые CASE-средствами СУБД (свыше 20 реляционных и
нереляционных БД).
С другой стороны, CASE-средства могут по содержимому системного
каталога или SQL-скрипту воссоздать физическую и логическую модели
данных. Это называется обратным проектированием. На основе полученной
логической модели генерируется физическая модель для другой СУБД и ее
системный каталог. Так можно решить задачу по переносу структуры данных
с одного сервера на другой.
Последовательность действий при создании логической модели
типична для любой среды визуального проектирования.
Пример нотации ER-модели – метод IDEF1X
Методики представления ER-моделей, используемые в разных
литературных источниках, а также в разных CASE-системах, несколько
отличаются друг от друга. В ряде CASE-средств (ERwin, ERStudio)
реализован метод IDEF1X, входящий в семейство стандартов IDEF.
Метод разработан для армии США и широко используется в
государственных учреждениях, финансовых и промышленных корпорациях.
Он прост в изучении и обеспечивает возможность автоматизации. Позволяет
построить модель данных, эквивалентную РМД, приведенной к 3НФ.
Автоматическая генерация базы данных
Последовательность действий при создании логической модели
типична для любой среды визуального проектирования. На панели
инструментов выбирается необходимый компонент (сущность, связь,
текстовый блок и т. д.) и размещается в окне логической модели.
Добавляемые сущности и атрибуты отображаются в Проводнике.
Генерация физической модели осуществляется автоматически. В
некоторых средствах используется Мастер, проводящий пользователя через
все этапы.
В CASE-средстве ER/Studio генерация физической модели
осуществляется по команде Create Physical Model за восемь шагов.
1. Определяется имя физической модели, из списка выбирается целевая
платформа будущей БД, принимается решение о проверке правильности
модели.
2. Выбираются объекты (таблицы), включаемые в физическую модель.
Определяется способ обработки внешних ключей от не вошедших в модель
таблиц.
3. Принимается решение о включении или невключении в физическую
модель подмоделей и текстовых блоков логической модели. Определяется
способ разрешения связей многие-ко-многим.
4. Определяется, какие индексы будут генерироваться для включаемых
таблиц (для первичных, альтернативных ключей, инверсионных входов и
т. д.). Принимается решение, будет ли добавляться префикс к названию
таблиц.
5. Определяется, как будут обрабатываться пробелы и символы
верхнего и нижнего регистра в названиях.
6. Выбирается логика проверки законченности и целостности таблиц
(таблицы без столбцов, таблицы без первичных ключей, таблицы с типом
данных по умолчанию, превышение разрешенного количества столбцов).
7. Выбирается логика проверки соглашения об именах (длина имен,
проверка ключевых слов, которые не должны использоваться как названия и
т. д.).
8. Выбирается способ проверки целостности индексов таблицы
(проверка таблиц без индексов, проверка таблиц с индексами,
превышающими пределы).
Настройки, предлагаемые Мастером по умолчанию, во многих случаях
можно оставить без изменений. По окончании генерации физической модели
формируется отчет с информацией об ошибках, обнаруженных в процессе
создания модели.
Следующим шагом является генерация кода. Возможны разные
варианты воплощения физической модели. Пользователь должен определить,
как реализовать ссылочную целостность, связи через первичные и внешние
ключи или через триггеры. Необходим план генерации индексов. Для
администратора БД важна настройка физических хранилищ и т. д. Эти
действия за семь шагов выполняет Мастер генерации БД, запускаемый
командой Generate Target SQL.
1. Выбираются таблицы и представления для включения в генерацию
кода БД.
2. Определяется, как будут реализованы первичные и альтернативные
ключи.
3. Определяется, будут ли генерироваться неуникальные индексы и
триггеры и как будет осуществляться ссылочная целостность.
4. Определяются параметры имеющихся в наличии физических
хранилищ.
5. Выбираются дополнительно к таблицам, индексам и триггерам
другие типы объектов БД. Можно генерировать правила, значения по
умолчанию, типы данных, определяемые пользователем, хранимые
процедуры и т. д.
6. Выбирается вариант генерации исходного текста SQL или генерации
объектов БД. Генерация SQL-скрипта позволяет создать БД в любое другое
время.
7. Принимается решение, будет ли использована для генерации
существующая БД или же создана новая. Создается источник данных ODBC.
После генерации БД на экран выводится отчет о создании БД.
Наиболее распространенная ошибка – задание типов данных, не
поддерживаемых выбранной платформой БД. После генерации БД работа с
CASE-средством закончена. Созданная БД может быть открыта уже
непосредственно из СУБД.
Состав электронных документов к контрольной работе:
1. Информационная система, построенная на основе концепции баз
данных, реализующая функции предметной области (т.е. спроектированная
Вами база данных)