КУРСОВАЯ РАБОТА
по дисциплине: Базы данных
на тему: «АИС для ГОУДОД Центра развития творчества детства и юношества»
Содержание
1.Теоретическая часть
1.1 Процессы проектирования
1.2 Инфологическое проектирование
2. 1 Специальная часть
2.1.1 Этапы выполнения курсовой работы
2.2 Технологическая часть
2.2.1 Физическое проектирование
2.3 Инструкция пользователю
Заключение
1. Теоретическая часть
Проектирование программных систем складывается из проектирования процессов, данных и событий. В силу специфики курса мы рассматриваем лишь проектирование данных – процесс разработки структуры базы данных в соответствии с требованиями заказчиков. В ходе разработки проекта нужно ответить на следующие вопросы:
· что представляют собой требования заказчиков, и в какой форме они выражены;
· как они преобразуются в структуру базы данных;
· как часто и каким образом структура базы данных должна перестраиваться.
В настоящее время рассматриваются три уровня абстракции для определения структуры данных: концептуальный (точка зрения заказчика), логический (точка зрения разработчика) и физический (точка зрения администратора БД). В соответствии с этим рассматриваются три уровня модели и три шага проектирования. Некоторые источники утверждают, что ни физической модели, ни шага физического проектирования на самом деле нет. Обсуждение этого взгляда проведем, когда уточним содержание всех трех видов абстракции.
Концептуальный уровень – наиболее общее представление об информационном содержании предметной области. Представляется в виде концептуальной модели (КМ), которая часто называется концептуальной схемой или информационной структурой. КМ обладает высокой степенью стабильности, она проблемно-ориентирована и не зависит от конкретной СУБД, операционной системы и аппаратного обеспечения. Ее поведение должно быть полностью предсказуемо.
Концептуальное представление оперирует основными элементарными данными предметной области, называемыми сущностями. Сущности описываются атрибутами. Данные могут находиться в некотором отношении друг с другом: образовывать ассоциации. Эти ассоциации называются связями. КМ должна поддерживать согласованность связей в пределах уровня детализации.
Обычно для концептуального представления используется модель «Сущность-Связь» (ER-модель), которая графически выражается ER-диаграммами. Существуют различные модификации представления (нотации) диаграмм. Ранее уже приводились сведения о ER-модели. Добавим, что, не только сущности, но и связи могут иметь атрибуты, выражающие их свойства. Представление модели внешне напоминает структуру базы данных и служит для отображения на логическую модель.
Логический уровень представления оперирует такими понятиями, как запись, компоненты записи, связи между записями. Соответствующая ему модель называется логической (ЛМ), она представляет собой отображение концептуальной модели в среду конкретной СУБД. Иногда рассматривают не конкретную СУБД, а только ее класс (модель) – иерархическую, сетевую или реляционную. Особенности этих моделей рассматривались ранее.
Физический уровень демонстрирует физическое хранение данных. На этом уровне используются такие понятия, как физические блоки, файлы, хранимые записи, указатели. Взаимосвязи между хранимыми записями, возникающие в процессе их группировки, а также индексные структуры тоже рассматриваются на уровне физической модели (ФМ). С точки зрения чистой базы данных можно абстрагироваться от физической модели представления данных, но знать ее очень полезно для достижения более высокой производительности системы. Если есть возможность влиять на ФМ и есть представление о способах оптимизации в ее рамках, воспользоваться ими может быть полезно, особенно для распределенных данных. Но реально почти никогда это не делается.
Есть и другая классификация уровней представления данных. Согласно стандарту ANSI/SPAC, архитектура БД представлена трехуровневой моделью с внешним, концептуальным и внутренним уровнями. В отличие от предыдущей модели, это не модель проектирования, модель оперирования данными.
Внешний уровень – описание на языке пользователя структуры данных, вида и формы их представления, а также описание операций манипулирования данными. Считается, что для описания предметной области используется несколько внешних моделей. Данный уровень содержит черты как КМ, так и ЛМ, описанных ранее.
Концептуальный уровень – наиболее общее представление об информационном содержании предметной области. Определение совпадает с приведенным ранее.
Внутренний уровень – организованная совокупность структурированных данных, отображение концептуальной модели в конкретную среду хранения. Легко видеть, что это понятие объединяет ранее определенные логическую и физическую модели.
Рассматривая эти два подхода к описанию представления данных, приходим к выводу, что первый более прагматичен. В нем предметная область рассматривается как единое целое, а не как совокупность проектных требований, называемых внешними моделями. Реально проектные требования редко можно назвать полноценной моделью, так как любая модель должна давать на каком-то уровне адекватное представление о предметной области. Полученные же требования зачастую выступают как совокупность представлений о ней разных групп пользователей. Такая ситуация возникает в тех случаях, когда аналитик считает, что пользователи формулируют свои знания как локальные модели, совокупность которых и должна составлять требуемую модель. Неверность этого утверждения хорошо иллюстрируется известной индийской сказкой об исследовании слона пятью слепцами, в ходе которого они предложили свои локальные модели слона (исследователь хобота считал, что слон похож на канат, хвоста – на метелку, бока – на стену, уха – на лист, ноги – на колонну). Реально пользователь часто не в состоянии построить даже локальную информационную модель, а про глобальные связи между ними и говорить не приходится. Другое соображение. Популярное в настоящее время направление проектирования – перепроектирование технологических процессов (реинжиниринг бизнес-процессов – BPR) – отрицает такой подход в силу того, что он консервирует существующую технологию и не дает выделить цель производства. А раз невозможно выделить общую цель производства, результат данного этапа исследования нельзя считать моделью. Но можно, введя понятие типа пользователя (эксперта), рассматривать соответствующую внешнюю модель как точку зрения этого эксперта на предметную область. В этом случае концептуальная модель представляется как единое целое, дополненное совокупностью точек зрения экспертов.
Инфологический подход не предоставляет формальных способов моделирования реальности, но он закладывает основы методологии проектирования баз данных.
Теперь рассмотрим три основных уровня проектирования: инфологическое, концептуальное и логическое – с точки зрения первого подхода.
1.2Инфологическое проектирование
Основными задачами инфологического проектирования являются определение предметной области системы и формирование взгляда на ПО с позиций сообщества будущих пользователей БД, т.е. инфологической модели ПО.
Инфологическая модель ПО представляет собой описание структуры и динамики ПО, характера информационных потребностей пользователей в терминах, понятных пользователю и не зависимых от реализации БД. Это описание выражается в терминах не отдельных объектов ПО и связей между ними, а их типов, связанных с ними ограничений целостности и тех процессов, которые приводят к переходу предметной области из одного состояния в другое.
На этапе концептуального проектирования определяются информационные потребности и локальные представления предметной области. Выявляется роль, назначение, взаимосвязь данных, проводится их глобальная спецификация. Результат этапа – описание объектов данных и их взаимосвязи без указания способа их физической организации. Структура данных представляется концептуальной схемой, содержащей набор сущностей, связей и атрибутов. Различаются две важных стадии концептуального проектирования: анализ данных и организация их хранения.
Содержание первой стадии – сбор полной и точной информации о данных предметной области. Заметим, что речь идет о первоначальном сборе информации, в процессе проектирования, как правило, выясняются дополнительные обстоятельства. Нередко для проведения данной работы прибегают к одному из двух методов (или к обоим): анкетированию и работе с экспертами. В первом случае пользователю предлагается анкета, в которой он должен дать свое представление о данных. Во втором случае среди пользователей выбирается группа экспертов, которые все и излагают. Оба этих метода страдают большими недостатками. Анкетирование никогда не гарантирует полноту информации: к этому процессу пользователи относятся как к досадной помехе в основной деятельности, поэтому стараются не дать точные сведения, а поскорее «отбиться». Работа с экспертами несколько лучше, но требует затрат квалифицированного труда. Кроме того, эксперты, будучи специалистами в своей области, не всегда способны достаточно внятно и полно изложить суть проблемы целиком. Тем не менее, не стоит пренебрегать этими методами, но за основу следует взять личное участие разработчиков в исследовании. В частности, следует потребовать набор выходных и входных документов и проследить их движение и модификацию на каждом этапе технологического процесса. Во время такого исследования выявляются недостатки принятого документооборота и делаются попытки, как это предлагает BPR, его оптимизировать с точки зрения машинной обработки.