Этап 1. Создание локальной концептуальной модели данных исходя из представления о предметной области каждого из типов пользователей

Приложения

А. Распечатки исходных данных контрольного примера.

В. Распечатки структуры базы данных (схема и таблицы).

С. Распечатки результатов (отчет) решения задачи по данным контрольного примера.

1.4. Задание на курсовое проектирование

Задание на курсовое проектирование содержит:

• текст индивидуального задания, на основании которого выполняется курсо­вое проектирование.

Курсовое проектирование ориентировано на использование СУБД.

Кафедра предлагает для курсового проектирования несколько предметных обла­стей. Студенту предоставляется право по согласованию с руководителем курсо­вого проекта предлагать свою тему курсового проекта.

Теоретический материал

Процесс разработки баз данных включает три фазы: концептуальное, логическое и физическое проектирование. Этапы, относящиеся к каждой из трех основных фаз, определяются методологией проектирования баз данных. Методология проектирования – структурированный подход, предусматривающий использование специализированных процедур, технических приемов, инструментов, документации и нацеленный на поддержку и упрощение процесса проектирования.

Обобщенное формальное описание методологии проектирования реляционных баз данных.

Этап 1. Создание локальной концептуальной модели данных исходя из представления о предметной области каждого из типов пользователей.

Концептуальное проектирование – процедура конструирования информационной модели предприятия, не зависящей от каких – либо физических условий реализации. Фаза концептуального проектирования базы данных начинается с создания концептуальной модели данных предприятия, полностью независимой от любых деталей реализации. К последним относятся: выбранный тип СУБД, состав программ приложения и любые другие физические особенности реализации. Этот этап состоит из следующих разделов:

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

Определение типов связей. Определение важнейших типов связей, существующих между сущностями, выделенными на предыдущем этапе. Определение кардинальности связей и ограничений участия его членов. Документирование типов связей.

Определение атрибутов и связывание их с типами сущностей и связей. Связывание атрибутов с соответствующими типами сущностей или связей. Идентификация простых и составных атрибутов, простых и множественных атрибутов, а также производных атрибутов. Документирование сведений об атрибутах.

Определение доменов атрибутов. Определение доменов для атрибутов в каждой локальной концептуальной модели данных. Документирование сведений о доменах атрибутов.

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

Специализация или генерация типов сущностей (необязательный этап). Определение суперклассов и подклассов для типов сущностей (при необходимости)

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

Этап 2. Построение и проверка локальной логической модели данных на основе представления о предметной области каждого из типов пользователей

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

Преобразование локальной концептуальной модели данных в локальную логическую модель. Доработка локальных концептуальных моделей с целью удаления из них нежелательных элементов и преобразование полученных моделей в локальные логические модели данных. Удаление связей типа M:N, сложных связей, рекурсивных связей, множественных атрибутов, связей с атрибутами и избыточных связей. Перепроверка связей типа 1:1.

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

Проверка модели с помощью правил нормализации (*). Проверка локальной логической модели данных с использованием технологии нормализации. Целью выполнения этого этапа является получение гарантий того, что каждое из отношений, созданных на основе логической модели данных, отвечает, по крайней мере, требованиям НФБК (нормальной формы Бойса - Кодда).

Проверка модели в отношении транзакций пользователей (**) (необязательный этап). Цель выполнения этапа – убедиться в том, что локальная логическая модель данных позволяет выполнить все транзакции, предусмотренные данным представлением пользователя.

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

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