ОТЧЕТНАЯ ДОКУМЕНТАЦИЯ
По результатам курсового проектирования должен быть представлен отчет, который включает описание всех этапов работы. Примерная структура отчета приведена в данном разделе, а оформление проекта – в приложениях I и II. Все этапы создания БД и разработки информационной системы должны быть документированы. В ходе проектирования и реализации создается рабочая ( промежуточная) документация : описания, схемы, тесты, распечатки. Некоторые из рабочих документов в дальнейшем войдут в состав отчетной ( окончательной ) документации. Структура отчета курсового проекта по курсу «Управление данными» приведена в приложении. Отчетная документация по курсовому проекту должна включать следующие разделы :
ОПИСАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ Описание предметной области ( ПО ) должно охватывать реальные объекты и процессы, содержать всю необходимую информацию для удовлетворения предполагаемых запросов пользователя и определять потребности в обработке данных - конкретные задачи пользователя. Должны быть приведены ограничения ПО, касающиеся выполнения конкретного индивидуального задания. ПРОЕКТИРОВАНИЕ БД База данных - это датологическое ( в виде данных ) представление информационной модели предметной области. Процесс разработки БД представляет собой процесс реализации отображения ПО <------------------ > модель <---------- > физическая БД Для реализации процесса разработки БД наиболее эффективным является трехуровневый подход к проектированию модели данных, включающий внешний, концептуальный и внутренний уровни представления данных. При таком подходе на внешнем уровне реализуются модели предметной области в виде, требуемом для отдельных пользователей. На концептуальном уровне поддерживается модель ПО для всех приложений. Хранимые данные также представляют ПО для всех приложений, но они выделены в отдельный - внутренний уровень. В процессе проектирования БД разрабатываются схемы моделей названных уровней, проверяется возможность отображения объектов модели одного уровня объектами модели другого уровня. При такой архитектуре БД обладает высокой способностью адаптации к возможным изменениям, как в самих данных, так и в прикладных программах. Основным уровням абстрагирования предшествует еще один - информационный. Модель этого уровня - инфологическая модель ПО - должна выражать информацию о ПО в виде, независимом от используемой СУБД и опираться на знания всех пользователей. 2.1.Описание БД в терминах объектов П О Проектирование БД начинается с предварительной структуризации предметной области : объекты реального мира подвергаются классификации, фиксируется совокупность подлежащих отображению в БД объектов. Для каждого объекта фиксируется совокупность свойств, посредством которых будут описываться конкретные экземпляры объекта, и отношения ( взаимосвязи ) с другими объектами. Затем решаются вопросы о том, какая информация об объектах должна быть представлена в БД и как ее представить с помощью данных. Объектная система имеет следующие основные составляющие: объект, свойство, связь ( объектное отношение ). Объект - это то, о чем накапливается информация. Каждый объект характеризуется определенным состоянием, которое описывается с помощью ограниченного набора свойств и связей ( отношений ) с другими объектами. Свойства объекта могут не зависеть от его связей с другими объектами, т.е. являются локальными. Если свойства объекта зависят от связей с другими объектами, то они называются реляционными. Связь между объектами в зависимости от числа входящих в нее объектов характеризуется степенью: n = 2,3,...k. На этом этапе проектирования Базы ланных необходимо определить: — какие объекты важны для применения; — какие свойства могут иметь эти объекты; — какие связи существуют между объектами. 2.2. Построение информационной структуры ПО Концептуальная модель применяется для структурирования ПО с учетом информационных потребностей самой ПО и информационных интересов пользователей системы и независима от конкретной СУБД. Для проектирования концептуальной схемы ( информационной структуры ПО ) можно использовать различные модели, например, бинарные модели и модели «сущность - связь». Из моделей типа «сущность - связь» наиболее известна модель П.Чена, или ER - модель. Общим для всех моделей этого типа является использование трех основных конструкций : сущность, атрибут и связь. Сущность - собирательное понятие, некоторая абстракция реально существующего объекта, процесса или явления, о котором необходимо хранить информацию. Тип сущности определяет множество подобных экземпляров объекта, а экземпляр сущности - конкретный экземпляр объекта. Каждый рассматриваемый в модели тип сущности должен быть поименован. Атрибут - поименованная характеристика сущности, которая принимает значение из некоторого множества значений. В модели атрибут выступает в качестве средства, с помощью которого моделируются свойства сущностей. Связь - средство представления отношения между сущностями. Могут встречаться бинарные ( между двумя сущностями ) и в общем случае n - арные связи. Для каждой сущности необходимо указать идентификатор, служащий для однозначного распознавания экземпляров сущности. В качестве идентификатора служит один атрибут или совокупность атрибутов - составной атрибут, который называют ключом. Если совокупность атрибутов, описывающих объект, не содержит ключа, то в состав атрибутов вводится специальный атрибут, выступающий в качестве ключа. Во многих случаях это некоторый последовательный номер. Один и тот же объект может иметь несколько ключей. Один из них назначается первичным ( главным ) ключом, все остальные ключи объекта называются возможными ключами. Ключ должен выполнять свою главную задачу - однозначной идентификации экземпляра объекта - и включать в свой состав минимально необходимое количество атрибутов. На языке ER - модели концептуальная схема может быть представлена ER - диаграммой, в которой множество сущностей обозначается прямоугольниками, множество связей - ромбами. На ER - диаграмме допустимо обозначать множество атрибутов овалами, соединяя их с соответствующими типами сущностей; ключевые атрибуты подчеркиваются. 2.3. Представление БД реляционной моделью. Основной задачей логического проектирования является разработка логической схемы, ориентированной на выбранную СУБД. Так как подавляющее большинство современных СУБД - реляционные, то и концептуальную модель БД следует отображать на реляционную модель. В основе реляционной модели используется понятие "отношения", которое используется для представления 1) набора экземпляров объекта ( сущности ), 2) отношений ( связей ) между объектами. Отношение представляется как определенным образом организованная таблица ( см. раздел 1 ). Для отображения информационной структуры ПО на логическую схему реляционной БД следует получить ответы на вопросы: - сколько таблиц и какие должна включать БД; - каковы степень ( число столбцов ) и состав каждой таблицы; - какие атрибуты ( поля ) используются в качестве ключей; - как устанавливаются связи между разными таблицами: а) использование в разных таблицах одного и того же ключа, б) помещение ключа одной таблицы в качестве атрибута ( поля ) в в) создание специальных связующих таблиц; - как обеспечить полноту, непротиворечивость и согласованность ин Для уменьшения избыточности информации и исключения аномалий выполняется нормализация исходных схем отношений проекта БД. ©2015 arhivinfo.ru Все права принадлежат авторам размещенных материалов.
|