Министерство  образования и науки Российской Федерации 

Государственное образовательное учреждение высшего 

профессионального образования

«РЯЗАНСКИЙ  ГОСУДАТСТВЕННЫЙ РАДИОТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ» 

Кафедра ЭВМ 
 
 
 

                                                                                                    К защите            

                                                                                                     Руководитель проекта

                                                                                                                      _____________________________

                                                                                                                                                дата, подпись 
 
 

ПОЯСНИТЕЛЬНАЯ ЗАПИСКА

К КУРСОВОМУ ПРОЕКТУ

по дисциплине

«Системы управления базами данных» 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

Рязань 2009

Оглавление

 

1. Теоретическая часть

 

       Современные информационные технологии - это методы и средства для сбора, хранения, обработки  и получения информации на основе современных средств вычислительной техники.

     Составными  частями любой информационной системы  являются базы данных и приложение для обработки данных.

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

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

       При проектировании базы данных решаются две  основные проблемы:

       1.Отображение  объектов предметной области  в абстрактные объекты модели  данных таким образом, чтобы  это отображение не противоречило  семантике предметной области,  и было по возможности лучшим (эффективным, удобным и т.д.). Часто эту проблему называют проблемой логического проектирования баз данных;

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

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

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

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

       Моделирование данных – это процесс создания логического представления структуры  базы данных.

       Эта структура должна удовлетворять  представления пользователя данными.

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

       В настоящее время существует два различных подхода к моделированию данных:

1. модель базы данных типа «сущность - связь» (entity-relationship model), имеющая значительное количество сторонников среди профессионалов;
2. семантическая объектная модель (некоторые считают ее более простой и точной).

       При проектировании базы данных используем первый, наиболее распространенный метод моделирования данных – «сущность - связь».

       Эта модель введена Питером Ченом в 1976 году.

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

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

       Инфологическая  модель является проблемно-ориентированной  и системно-независимой, т.е. не зависимой от конкретной СУБД, операционной системы и аппаратного обеспечения ЭВМ.

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

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

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

       Центральной компонентой инфологической модели является описание объектов предметной области и связей между ними (ER-модель).

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

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

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

       Экземпляр сущности относится к конкретной вещи в наборе. Например, типом сущности может быть ГОРОД, а экземпляром – Москва, Киев и т.д.

       Атрибут – поименованная характеристика сущности.

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

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

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

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

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

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

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

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

       В терминах БД столбцы таблицы называются полями, а ее строки - записями.

       Нормализация  выполняется поэтапно. Первые три  шага были описаны доктором Э.Ф. Коддом в статье "Дальнейшая нормализация реляционной модели базы данных" в 1972г.

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

       Никакую из систем управления базами данных (СУБД) не удовлетворяет только 1НФ, так как в этом случае необходимо определить большое число полей, многие из которых остаются в основном пустыми. Избыточные данные могут послужить причиной проблем целостности и снижение эффективности при внесении изменений, поэтому подобных решений при проектировании баз данных необходимо избегать.