Главная | Обратная связь

ОТЧЕТНАЯ ДОКУМЕНТАЦИЯ

По результатам курсового проектирования должен быть представлен отчет, который включает описание всех этапов работы. При­мерная структура отчета приведена в данном разделе, а оформление проекта – в приложениях I и II.

Все этапы создания БД и разработки информационной систе­мы должны быть документированы. В ходе проектирования и реализации соз­дается рабочая ( промежуточная) документация : описания, схемы, тесты, рас­печатки. Некоторые из рабочих документов в дальнейшем войдут в состав отчетной ( окончательной ) документации.

Структура отчета курсового проекта по курсу «Управление данными» приведе­на в приложении.

Отчетная документация по курсовому проекту должна включать сле­дующие разделы :

 

ОПИСАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ

Описание предметной области ( ПО ) должно охватывать реальные объ­екты и процессы, содержать всю необходимую информацию для удовлетво­рения предполагаемых запросов пользователя и определять потребности в об­работке данных - конкретные задачи пользователя.

Должны быть приведены ограничения ПО, касающиеся выполнения конкретного индивидуального задания.

ПРОЕКТИРОВАНИЕ БД

База данных - это датологическое ( в виде данных ) представление информационной модели предметной области.

Процесс разработки БД представляет собой процесс реализации отобра­жения

ПО <------------------ > модель <---------- > физическая БД

Для реализации процесса разработки БД наиболее эффективным является трехуровневый подход к проектированию модели данных, включающий внешний, концепту­альный и внутренний уровни представления данных.

При таком подходе на внешнем уровне реализуются модели предметной области в виде, требуемом для отдельных пользователей. На концептуальном уровне поддерживается модель ПО для всех приложений. Хранимые данные также представляют ПО для всех приложений, но они выделены в отдельный - внутренний уровень.

В процессе проектирования БД разрабатываются схемы моделей назван­ных уровней, проверяется возможность отображения объектов модели одного уровня объектами модели другого уровня.

При такой архитектуре БД обладает высокой способностью адаптации к возможным изменениям, как в самих данных, так и в прикладных программах.

Основным уровням абстрагирования предшествует еще один - инфор­мационный. Модель этого уровня - инфологическая модель ПО - должна вы­ражать информацию о ПО в виде, независимом от используемой СУБД и опи­раться на знания всех пользователей.

2.1.Описание БД в терминах объектов П О

Проектирование БД начинается с предварительной структуризации предметной области : объекты реального мира подвергаются классификации, фиксируется совокупность подлежащих отображению в БД объектов. Для ка­ждого объекта фиксируется совокупность свойств, посредством которых бу­дут описываться конкретные экземпляры объекта, и отношения ( взаимосвязи ) с другими объектами. Затем решаются вопросы о том, какая информация об объектах должна быть представлена в БД и как ее представить с помощью данных.

Объектная система имеет следующие основные составляющие: объект, свойство, связь ( объектное отношение ).

Объект - это то, о чем накапливается информация.

Каждый объект характеризуется определенным состоянием, которое описывается с помощью ограниченного набора свойств и связей ( отношений ) с другими объектами.

Свойства объекта могут не зависеть от его связей с другими объектами, т.е. являются локальными. Если свойства объекта зависят от связей с другими объектами, то они называются реляционными.

Связь между объектами в зависимости от числа входящих в нее объек­тов характеризуется степенью: n = 2,3,...k.

На этом этапе проектирования Базы ланных необходимо определить:

— какие объекты важны для применения;

— какие свойства могут иметь эти объекты;

— какие связи существуют между объектами.

2.2. Построение информационной структуры ПО

Концептуальная модель применяется для структурирования ПО с уче­том информационных потребностей самой ПО и информационных интересов пользователей системы и независима от конкретной СУБД.

Для проектирования концептуальной схемы ( информационной структу­ры ПО ) можно использовать различные модели, например, бинарные модели и модели «сущность - связь».

Из моделей типа «сущность - связь» наиболее известна модель П.Чена, или ER - модель. Общим для всех моделей этого типа является использование трех основных конструкций : сущность, атрибут и связь.

Сущность - собирательное понятие, некоторая абстракция реально су­ществующего объекта, процесса или явления, о котором необходимо хранить информацию.

Тип сущности определяет множество подобных экземпляров объекта, а экземпляр сущности - конкретный экземпляр объекта. Каждый рассматривае­мый в модели тип сущности должен быть поименован.

Атрибут - поименованная характеристика сущности, которая принима­ет значение из некоторого множества значений. В модели атрибут выступает в качестве средства, с помощью которого моделируются свойства сущностей.

Связь - средство представления отношения между сущностями.

Могут встречаться бинарные ( между двумя сущностями ) и в общем случае n - арные связи.

Для каждой сущности необходимо указать идентификатор, служащий для однозначного распознавания экземпляров сущности. В качестве иденти­фикатора служит один атрибут или совокупность атрибутов - составной атри­бут, который называют ключом. Если совокупность атрибутов, описывающих

объект, не содержит ключа, то в состав атрибутов вводится специальный ат­рибут, выступающий в качестве ключа. Во многих случаях это некоторый по­следовательный номер.

Один и тот же объект может иметь несколько ключей. Один из них на­значается первичным ( главным ) ключом, все остальные ключи объекта назы­ваются возможными ключами.

Ключ должен выполнять свою главную задачу - однозначной иденти­фикации экземпляра объекта - и включать в свой состав минимально необхо­димое количество атрибутов.

На языке ER - модели концептуальная схема может быть представлена ER - диаграммой, в которой множество сущностей обознача­ется прямоугольниками, множество связей - ромбами. На ER - диаграмме до­пустимо обозначать множество атрибутов овалами, соединяя их с соответст­вующими типами сущностей; ключевые атрибуты подчеркиваются.

2.3. Представление БД реляционной моделью.

Основной задачей логического проектирования является разработка ло­гической схемы, ориентированной на выбранную СУБД. Так как подавляющее большинство современных СУБД - реляционные, то и концептуальную мо­дель БД следует отображать на реляционную модель.

В основе реляционной модели используется понятие "отношения", ко­торое используется для представления

1) набора экземпляров объекта ( сущности ),

2) отношений ( связей ) между объектами.

Отношение представляется как определенным образом организованная таблица ( см. раздел 1 ).

Для отображения информационной структуры ПО на логическую схему реляционной БД следует получить ответы на вопросы:

- сколько таблиц и какие должна включать БД;

- каковы степень ( число столбцов ) и состав каждой таблицы;

- какие атрибуты ( поля ) используются в качестве ключей;

- как устанавливаются связи между разными таблицами:

а) использование в разных таблицах одного и того же ключа,

б) помещение ключа одной таблицы в качестве атрибута ( поля ) в
записи другой таблицы,

в) создание специальных связующих таблиц;

- как обеспечить полноту, непротиворечивость и согласованность ин­
формации, хранящейся в БД.

Для уменьшения избыточности информации и исключения аномалий выполняется нормализация исходных схем отношений про­екта БД.