Федеральное агентство по образованию
Государственное образовательное учреждение высшего профессионального образования
Тульский государственный университет
КАФЕДРА ЭЛЕТРОННЫХ ВЫЧИСЛИТЕЛЬНЫХ МАШИН
УТВЕРЖДАЮ
Декан факультета кибернетики
________________ В.С. Карпов
Дата ________________
Базы данных
Методические указания к выполнениюкурсовой работы
Направление подготовки: 230100 «Информатика и вычислительная техника»
Специальность подготовки: 230101 «Вычислительные машины, комплексы,
системы и сети»
Форма обучения – очная
Тула 2008 г.
1. Цель выполнения контрольно-курсовой работы
Приобретение навыков работы с системами управления базами данных (СУБД). Изучить принципы организации и построения БД. Выбрать предметную область и спроектировать БД. Разработать БД в среде MS SQL Server. Осуществить заполнение БД. Разработать SQL запросы к БД .
2. Порядок выполнения контрольно-курсовой работы
Основная цель процесса проектирования БД состоит в получении такого проекта, который удовлетворяет следующим требованиям:
1. Корректность схемы БД, т.е. база должна быть гомоморфным образом моделируемой ПО, где каждому объекту ПО соответствуют данные в памяти ЭВМ, а каждому процессу – адекватные процедуры обработки данных.
2. Обеспечение ограничений (на объёмы внешней и оперативной памяти и другие ресурсы вычислительной системы).
3. Эффективность функционирования (соблюдение ограничений на время реакции системы на запрос и обновление данных).
4. Защита данных (от сбоев и несанкционированного доступа).
5. Простота и удобство эксплуатации.
6. Гибкость, т.е. возможность развития и адаптации к изменениям ПО и/или требований пользователей.
Удовлетворение первых 4-х требований обязательно для принятия проекта.
Процесс проектирования БД включает в себя следующие этапы:
1. Информационно-логическое (инфологическое) проектирование.
2. Определение требований к операционной обстановке, в которой будет функционировать информационная система.
3. Выбор СУБД и других инструментальных программных средств.
4. Логическое проектирование БД.
5. Физическое проектирование БД.
Этап 1. Инфологическое проектирование
Инфологический подход не предоставляет формальных способов моделирования реальности, однако он закладывает основы методологии проектирования БД.
Первой задачей инфологического проектирования является определение ПО системы, позволяющее изучить информационные потребности будущих пользователей. Другая задача этого этапа – анализ ПО, который призван сформировать взгляд на ПО с позиций сообщества будущих пользователей БД, т.е. инфологической модели ПО. Анализ ПО выполняется разработчиком логической базы данных – специалистом в данной ПО.
Инфологическая модель ПО представляет собой описание структуры и динамики ПО, характера информационных потребностей пользователей системы в терминах, понятных пользователю и независимых от реализации системы. Более того, инфологическая модель ПО не должна зависеть от модели данных, которая будет использована при создании БД.
Обычно описание ПО выражается в терминах не отдельных объектов и связей между ними, а их типов, связанных с ними ограничений целостности и тех процессов ПО, которые приводят к переходу ПО из одного состояния в другое. Такое описание может быть представлено любым способом, допускающим однозначную интерпретацию.
В простых случаях описание ПО представляется на естественном языке, в более сложных используется также математический аппарат: таблицы, диаграммы, графы и т.п.
При выполнении курсовой работы необходимо придериваться следующих обозначений:
-
Имя отношения выделяется курсивом и подчеркиванием и пишется прописными буквами, например: СОТРУДНИКИ.
-
Имя атрибута отношения выделяется курсивом и подчеркиванием и пишется с большой буквы, например: Оклад.
-
Ключевые атрибуты отношения выделяются полужирным шрифтом, например: Табельный номер.
-
Имя связи между отношениями выделяется курсивом и подчеркиванием и пишется строчными буквами, например: работает.
Построение инологической модели базы данных необходимо производить с использованием метода "сущность–связь".
Необходимо разбить ПО на ряд локальных областей, каждая из которых (в идеале) включает в себя информацию, достаточную для обеспечения информационных потребностей одной группы будущих пользователей или решения отдельной задачи. Каждое локальное представление моделируется отдельно, а затем выполняется их объединение. Выбор локального представления зависит от масштабов ПО. Обычно ПО разбивается на локальные области так, чтобы каждая из них соответствовала отдельному внешнему приложению и содержала 6-7 сущностей (т.е. объектов, о которых в системе будет накапливаться информация).
Для каждой сущности определяются атрибуты, которые делятся на два типа: идентифицирующие и описательные. Идентифицирующие атрибуты входят в состав ключа (или ключей) и позволяют однозначно распознавать экземпляры сущности. Первичный ключ базовой сущности не может содержать неопределённые значения атрибутов (null). Первичный ключ должен включать в свой состав минимально необходимое для идентификации количество атрибутов. Описательные атрибуты заключают в себе свойства сущности, интересующие пользователей.
Спецификация атрибута состоит из его названия, указания типа данных и описания ограничений целостности – множества значений, которые может принимать данный атрибут.
Далее осуществляется спецификация связей: выявляются связи между сущностями внутри локального представления. Каждая связь именуется. Кроме спецификации связей типа "сущность – сущность", выполняется спецификация связей типа "сущность – атрибут" и "атрибут – атрибут" для отношений между атрибутами, которые относятся к одной и той же сущности или к одной и той же связи типа "сущность – сущность".
При объединении проектировщик может формировать конструкции, производные по отношению к тем, которые были использованы в локальных представлениях. Цель введения подобных абстракций:
-
объединение в единое целое фрагментарных представлений о различных свойствах одного и того же объекта;
-
введение абстрактных понятий, удобных для решения задач системы, установление их связи с более конкретными понятиями модели;
-
образование классов и подклассов подобных объектов (например, класс "изделие" и подклассы типов изделий, производимых на предприятии).
При небольшом количестве локальных областей (не более пяти) объединение выполняется за один шаг. В противном случае обычно выполняют бинарное объединение. При объединении представлений используют три основополагающие концепции:
1. Идентичность. Два или более элементов модели идентичны, если они имеют одинаковое семантическое значение.
2. Агрегация. Позволяет рассматривать связь между элементами как новый элемент. Например, связь экзамен между сущностями СТУДЕНТ, ДИСЦИПЛИНА, ПРЕПОДАВАТЕЛЬ может быть представлена агрегированной сущностью ЭКЗАМЕН с атрибутами Название дисциплины, Фамилия преподавателя, Фамилия студента, Оценка.
3. Обобщение. Позволяет образовывать многоуровневую иерархию обобщений.
По завершении объединения результаты проектирования представляют собой концептуальную инфологическую модель ПО. Модели локальных представлений – это внешние инфологические модели.
БД publications должна хранить сведения о печатных изданиях, а также ссылки на интересные ресурсы в Internet. И те и другие источники информации будут касаться одной темы, а именно "баз данных". Попробуем выделить интересующие нас сущности и определить связи между ними.
Прежде всего займемся понятием "печатное издание". Что это такое? Мы знаем, что объект "печатное издание" воплощается в виде книги, которую можно полностью описать с помощью следующих характеристик: название, автор, год издания и издатель (издательство). Можно ли на основании этого ввести сущность "книга", а названные характеристики определить в качестве ее атрибутов? Прежде чем сделать это рассмотрим более внимательно отношения между книгой и ее харакетристиками:
Один автор может написать несколько книг, и, в то же время, одна книга может быть написана несколькими авторами. Следовательно, "книга" и "автор" в данном случае выступают как различные сущности, объединяемые связью N : M. Для того, чтобы определить класс принадлежности сущностей в связи, отметим, что книг без авторов не бывает, как и авторов без книг. Значит, каждая сущность должна иметь обязательный класс принадлежности (кардинальность связи(1,N) : (1,N)).
Точно так же один издатель может издавать сразу несколько книг, но каждая конкретная книга издается только в одном месте. Следовательно, мы должны ввести сущность "издатель", ассоциируемую с "книгой" связью типа 1 : N. Т.к. каждая книга кем-то издана, класс принадлежности сущности "издатель" в данной связи будет (1,1), но в то же время мы допускаем хранение сведений об издательствах, чьих книг в нашей базе данных пока нет. Соответственно, класс принадлежности сущности "книга" в этой связи (0,N).
По поводу характеристики книги "название" можно сказать следующее: как правило авторы, пишущие на одну тему, стараются придумывать для своих призведений оригинальные названия. Поэтому, можно уверенно предположить, что каждое название обязательно связано только с одной книгой (и каждая книга имеет только одно название). Следовательно, "название" нужно оставить в списке атрибутов "книги".
Те же рассуждения можно повторить и для характеристики "год издания". Ее мы тоже оставим в списке атрибутов "книги".
Таким образом, мы определили, что у сущности "книга" имеется два атрибута "название" и "год издания". Как уже говорилось, название, скорее всего, будет однозначно определять данную книгу, чего не скажешь о годе издания. Поэтому объявим ключом сущности атрибут "название" (или "имя_книги").
Что касается всех возможных авторов, то нас интересует только одна их харакетристика - имя. Поэтому, сущность "автор" имеет только один атрибут "имя_автора", который и является ключом.
С сущностью "издатель" дел обстоит несколько сложнее. Практически все крупные издательства имеют сейчас собственные web-страницы, которые могут содержать информацию полезную для пользователей проектируемой базы данных. Поэтому, нужно рассматреть две характеристики этого объекта: "имя_издателя" и "URL" (uniform resource locator - универсальный указатель ресурсов, с помощью которого в Internet определяется путь к web - странице). Ясно, что каждый издатель имеет уникальное имя и уникальный url, но прежде чем внести их в список атрибутов, вспомним, что наша база данных должна также содержать ссылки и на другие Internet-ресурсы. Возможно, при дальнейшем анализе возникнет необходимость во введении отдельной сущности "URL". Поэтому "имя_издателя" внесем в список атрибутов сущности "издатель", а "URL" будем считать атрибутом отдельной сущности "web - страница", ассоциируемой с "издателем" связью (1,1):(1,1).
Теперь настала пора занятся объектом "ресурс Internet". Его мы можем описать с помощью понятий "имя ресурса", "url", "автор". Внимательно рассмотрев связи этих понятий с описываемым объектом, можно прийти к заключению, что "имя_ресурса" и "url" однозначно с ним связаны, т.е. являются атрибутами. В то же время, "автор" является отдельной сущностью (один ресурс может иметь много авторов, и один автор может быть создателем многих web - страниц). Т.к. мы уже ранее вввели сущность "автор" просто определим характеристики ее связи с сущностью "Internet-ресурс". Из сказанного выше следует, что эти сущности объединяются связью n : m, в то же время, автор какой-либо книги может не иметь собственной web - страницы, а авторы некоторых Internet ресурсов не указывают своих имен (т.е. можно формально сказать, что эти ресурсы не имеют авторов). Следовательно, класс принадлежности обеих сущностей будет необязательным.
Прежде чем объявить нашу модель готовой, проверим еще раз определение каждой сущности. Внимательный анализ покажет, что построенная модель имеет несколько ошибок:
Сущность "автор" имеет обязательный класс принадлежности в связи с сущностью "книга". Это означает, что мы не сможем добавить в базу данных сведения о человеке, который создал собственный web - сайт, но не написал ни одной книги. Для того, что бы устранить это ограничение изменим класс принадлежности сущности "книга" в рассматриваемой связи "автор" - "книга" на необязательный.
При анализе объекта "издатель" мы предположили, что сущность "web-страница" может быть объединена с сущностью "Internet-ресурс". Однако, мы видим, что эти сущности имеют разный набор атрибутов, следовательно выполнить такое объединение нельзя. Вспомним, что в противном случае, предполагалось единственный атрибут сущности "web - страница" присоединить к атрибутам сущности "издатель". Тем не менее, не будем этого делать, в следующем разделе мы увидим, что с помощью правил порождения реляционных отношений из модели "сущность-связь" в том и в другом случае мы получим одинаковый результат.
Готовая модель "сущность-связь" представлена на следующем рисунке:
На этапе анализа ПО также необходимо решить следующие задачи:
1. Определить правила (ограничений целостности), которым должны удовлетворять сущности ПО, атрибуты сущностей и связи между ними. Часть этих правил реализуется в схеме базы данных (возможности реализации ограничений целостности в схеме БД определяются моделью данных той СУБД, которая будет выбрана для реализации проекта). Остальные правила реализуются с помощью программного обеспечения.
2. Выделить группы пользователей системы. Каждая группа выполняет определённые задачи и обладает разными правами доступа к системе.
3. Создать внешнюю спецификацию тех функций (процессов), которые эта система будет выполнять. Например, для той же библиотечной системы это задачи поиска книг (по определённым критериям), выдачи/приёма книг, определение списка должников и т.д.
Этап 2. Определение требований к операционной обстановке
На этом этапе производится оценка требований к вычислительным ресурсам, необходимым для функционирования системы, выбор типа и конфигурации ЭВМ, типа и версии операционной системы.
Выбор зависит от таких следующих показателей:
-
примерный объём данных в БД;
-
динамика роста объёма данных;
-
характер запросов к данным (извлечение и обновление отдельных записей, групп записей, обработка отдельных отношений или соединение отношений);
-
интенсивность запросов к данным по типам запросов;
-
требования к времени отклика системы по типам запросов.
Этап 3. Выбор СУБД и инструментальных программных средств
Выбор СУБД является одним из важнейших моментов в разработке проекта БД, так как он принципиальным образом влияет на весь процесс проектирования БД и реализации информационной системы.
Теоретически при осуществлении этого выбора нужно принимать во внимание десятки факторов. Но на практике разработчики руководствуются лишь собственной интуицией и несколькими наиболее важными критериями, к которым, в частности, относятся:
-
тип модели данных, которую поддерживает данная СУБД, адекватность модели данных структуре рассматриваемой ПО;
-
характеристики производительности СУБД;
-
запас функциональных возможностей для дальнейшего развития информационной системы;
-
степень оснащенности СУБД инструментарием для персонала администрирования данными;
-
удобство и надежность СУБД в эксплуатации;
-
стоимость СУБД и дополнительного программного обеспечения.
В связи с тем. что в данной работе СУБД задается в задании, на данном этапе решается задача выбра инструментального ПО.
Этап 4. Логическое проектирование БД
На этапе логического проектирования разрабатывается логическая структура БД, соответствующая инфологической модели ПО. Решение этой задачи существенно зависит от модели данных, поддерживаемой выбранной СУБД. Результатом выполнения этого этапа являются схемы БД концептуального и внешнего уровней архитектуры, составленные на языках определения данных (DDL) выбранной СУБД.
При этом разработка логической структуры базы данных должна производиться с учетом соблюдения условий нормализации отношений.
На начальном шаге логического проектирования таблцы строятся такм образом, чтобы минимизировать количество таблиц в базе данных. Очевдино, что при таком подходе отношения не будут находиться ни в одной из нормальных форм, либо находиться в 1й нормальной форме. Необходимо последовательно привести каждую таблицу к 4й нормальной форме.
Ниже рассматривается отношение КНИГИ (табл. 3.1) и последовательность его приведения к 4й нормальной форме.
Id – идентификатор (первичный ключ),
Code – шифр рубрики,
Theme– название рубрики,
Title – название книги,
Author– автор,
Editor – редактор,
Type – тип издания (учебник, учебное пособие, сборник и.т.п.),
Year – год издания,
Pg – количество страниц.
Таблица 3.1. Исходное отношение КНИГИ
ID
|
Code
|
Theme
|
Author
|
Title
|
Editor
|
Type
|
Year
|
Pg
|
200
|
681.3
|
ПО ВТ
|
Бочков С.
|
Язык СИ
|
Садчиков П.
|
учебник
|
1990
|
384
|
Субботин Д.
|
100
|
681.3
|
ПО ВТ
|
Джехани Н.
|
Язык АДА
|
|
учебник
|
1960
|
552
|
300
|
621.5
|
МО
|
Крон Г.
|
Диакоптика
|
Баранов А.
|
учебник
|
1972
|
544
|
876
|
007
|
ИИ
|
Гик Е.Я.
|
Шахматы и математика
|
Кикоин И.
|
учебное пособие
|
1983
|
176
|
Капица С.
|
440
|
32.97
|
ВТ
|
|
ПУ для ПЭВМ
|
Витенберг А.
|
справочник
|
1992
|
208
|
385
|
001.8
|
Инфор-матика
|
Фролов Г.
|
Элементы информатики
|
Храмов А.
|
учебное пособие
|
1989
|
304
|
Кузнецов Э.
|
Рожков П.
|
Примечание. В таблице 3.1 используются следующие сокращения:
ВТ – вычислительная техника;
ПО ВТ – программное обеспечение вычислительной техники;
МО – математическое обеспечение;
ИИ – искусственный интеллект.
Первая нормальная форма (1НФ).
Отношение приведено к 1НФ, если все его атрибуты простые.
Отношение КНИГИ содержит сложные атрибуты Author ("Авторы") и Editor ("Редакторы"). Для приведения к 1НФ требуется сделать ключ отношения составным – атрибуты ID, Author и Editor (табл. 3.2).
Таблица 3.2. Отношение КНИГИ, приведённое к 1НФ
ID
|
Code
|
Theme
|
Author
|
Title
|
Editor
|
Type
|
Year
|
Pg
|
200
|
681.3
|
ПО ВТ
|
Бочков С.
|
Язык СИ
|
Садчиков П.
|
учебник
|
1990
|
384
|
200
|
681.3
|
ПО ВТ
|
Субботин Д.
|
Язык СИ
|
Садчиков П.
|
учебник
|
1990
|
384
|
100
|
681.3
|
ПО ВТ
|
Джехани Н.
|
Язык АДА
|
|
учебник
|
1960
|
552
|
300
|
621.5
|
МО
|
Крон Г.
|
Диакоптика
|
Баранов А.
|
учебник
|
1972
|
544
|
876
|
007
|
ИИ
|
Гик Е.Я.
|
Шахматы и математика
|
Кикоин И.
|
учебное пособие
|
1983
|
176
|
876
|
007
|
ИИ
|
Гик Е.Я.
|
Шахматы и математика
|
Капица С.
|
учебное пособие
|
1983
|
176
|
440
|
32.97
|
ВТ
|
|
ПУ для ПЭВМ
|
Витенберг А.
|
Спра-вочник
|
1992
|
208
|
385
|
001.8
|
Инфор-матика
|
Фролов Г.
|
Элементы информатики
|
Храмов А.
|
учебное пособие
|
1989
|
304
|
385
|
001.8
|
Инфор-матика
|
Кузнецов Э.
|
Элементы информатики
|
Рожков П.
|
учебное пособие
|
1989
|
304
|
Вторая нормальная форма (2НФ).
Введём понятие функциональной зависимости. Пусть X и Y – атрибуты (группы атрибутов) некоторого отношения. Говорят, что Y функционально зависит от X, если в любой момент времени каждому значению X=х соответствует единственное значение Y=y (XY). (При этом любому значению Y=y может соответствовать несколько значений Х=(х1, х2,…)).
Атрибут X в функциональной зависимости XY называется детерминантом отношения.
В нормализованном отношении все неключевые атрибуты функционально зависят от ключа отношения. Говорят, что неключевой атрибут функционально полно зависит от составного ключа, если он функционально зависит от ключа, но не находится в функциональной зависимости ни от какой части составного ключа.
Отношение находится во 2НФ, если оно приведено к 1НФ и каждый неключевой атрибут функционально полно зависит от составного ключа.
Для того чтобы привести отношение ко 2НФ, нужно:
-
построить его проекцию, исключив атрибуты, которые не находятся в функционально полной зависимости от составного ключа;
-
построить дополнительные проекции на часть составного ключа и атрибуты, функционально зависящие от этой части ключа.
Ключом отношения КНИГИ (табл. 3.2) является комбинация полей (ID, Author, Editor). Все поля, не входящие в состав ключа, зависят только от идентификатора книги. Поэтому отношение должно быть разбито на два: КНИГИ (табл. 3.3) и КНИГИ–АВТОРЫ–РЕДАКТОРЫ (табл. 3.4). Эти отношения связаны по внешнему ключу, которым является поле ID.
Таблица 3.3. Отношение КНИГИ, приведённое к 2НФ
ID
|
Code
|
Theme
|
Title
|
Type
|
Year
|
Pg
|
200
|
681.3
|
ПО ВТ
|
Язык СИ для ПК
|
Учебник
|
1990
|
384
|
100
|
681.3
|
ПО ВТ
|
Язык АДА
|
Учебник
|
1960
|
552
|
300
|
621.5
|
МО
|
Диакоптика
|
Учебник
|
1972
|
544
|
876
|
007
|
ИИ
|
Шахматы и математика
|
учебное пособие
|
1983
|
176
|
440
|
32.97
|
ВТ
|
ПУ для ПЭВМ
|
Справочник
|
1992
|
208
|
385
|
001.8
|
Информатика
|
Элементы информатики
|
учебное пособие
|
1989
|
304
|
.
Таблица 3.4. Отношение КНИГИ–АВТОРЫ–РЕДАКТОРЫ (2НФ)
ID
|
Author
|
Editor
|
200
|
Бочков С.
|
Садчиков П.
|
200
|
Субботин Д.
|
Садчиков П.
|
100
|
Джехани Н.
|
|
300
|
Крон Г.
|
Баранов А.
|
876
|
Гик Е.Я.
|
Кикоин И.
|
876
|
Гик Е.Я.
|
Капица С.
|
440
|
|
Витенберг А.
|
385
|
Фролов Г.
|
Храмов А.
|
385
|
Кузнецов Э.
|
Рожков П.
|
Третья нормальная форма (3НФ).
Рассмотрим понятие транзитивной зависимости. Пусть X, Y, Z – атрибуты некоторого отношения. При этом X Y и Y Z, но обратное соответствие отсутствует, т.е. Z не зависит от Y или Y не зависит от X. Тогда говорят, что Z транзитивно зависит от X (X Z).
Отношение находится в 3НФ, если оно находится во 2НФ и в нем отсутствуют транзитивные зависимости.
Для отношения КНИГИ (табл. 3.3) атрибут Theme зависит от атрибута Code, а не от ключа (хотя название рубрики, естественно, соответствует её шифру). Поэтому для приведения отношения к 3НФ (табл. 3.5) нужно выделить из него ещё одно отношение РУБРИКАТОР (табл. 3.6).
Таблица 3.5. Отношение КНИГИ, приведённое к 3НФ
ID
|
Code
|
Title
|
Type
|
Year
|
Pg
|
200
|
681.3
|
Язык СИ для ПК
|
Учебник
|
1990
|
384
|
100
|
681.3
|
Язык АДА
|
Учебник
|
1960
|
552
|
300
|
621.5
|
Диакоптика
|
Учебник
|
1972
|
544
|
440
|
32.97
|
ПУ для ПЭВМ
|
Справочник
|
1992
|
208
|
876
|
007
|
Шахматы и математика
|
учебное пособие
|
1983
|
176
|
385
|
001.8
|
Элементы информатики
|
учебное пособие
|
1989
|
304
|
.
Таблица 3.6. Отношение РУБРИКАТОР, приведённое к 3НФ
Code
|
Theme
|
681.3
|
ПО ВТ
|
621.5
|
МО
|
007
|
ИИ
|
32.97
|
ВТ
|
001.8
|
Информатика
|
Четвертая нормальная форма (4НФ).
Введём понятие многозначной зависимости. Многозначная зависимость существует, если заданным значениям атрибута X соответствует множество, состоящее из нуля (или более) значений атрибута Y (X–»Y). Если в отношении присутствуют многозначные зависимости, то схема отношения должна находиться в 4НФ.
Различают тривиальные и нетривиальные многозначные зависимости. Тривиальной называется такая многозначная зависимость X–»Y, для которой Y Ì X или X U Y = R, где R – рассматриваемое отношение. Тривиальная многозначная зависимость не нарушает 4НФ. Если хотя бы одно из двух этих условий не выполняется (т.е. Y не является подмножеством X или X U Y состоит не из всех атрибутов R), то такая многозначная зависимость называется нетривиальной.
Отношение находится в 4НФ, если оно находится в 3НФ и в нем отсутствуют нетривиальные многозначные зависимости.
Для отношения КНИГИ–АВТОРЫ–РЕДАКТОРЫ (табл. 3.4) атрибуты Author и Editor зависит образуют две многозначные зависимости от первичного ключа, и при этом значения этих атрибутов не зависят друг от друга. Поэтому для приведения отношения к 4НФ нужно разбить его на два отношения КНИГИ–АВТОРЫ и КНИГИ–РЕДАКТОРЫ (табл. 3.7, 3.8).
Таблица 3.7. Отношение КНИГИ–АВТОРЫ (4НФ)
ID
|
Author
|
200
|
Бочков С.
|
200
|
Субботин Д.
|
100
|
Джехани Н.
|
300
|
Крон Г.
|
876
|
Гик Е.Я.
|
385
|
Фролов Г.
|
385
|
Кузнецов Э.
|
.
Таблица 3.8. Отношение КНИГИ–РЕДАКТОРЫ (4НФ)
ID
|
Editor
|
200
|
Садчиков П.
|
300
|
Баранов А.
|
876
|
Кикоин И.
|
876
|
Капица С.
|
440
|
Витенберг А.
|
385
|
Храмов А.
|
385
|
Рожков П.
|
Этап 5. Физическое проектирование БД
Этап физического проектирования заключается в увязке логической структуры БД и физической среды хранения с целью наиболее эффективного размещения данных, т.е. отображении логической структуры БД в структуру хранения. Решается вопрос размещения хранимых данных в пространстве памяти, выбора эффективных методов доступа к различным компонентам "физической" БД. Результаты этого этапа документируются в форме схемы хранения на языке определения хранимых данных. Принятые на этом этапе решения оказывают определяющее влияние на производительность системы.
Фактически проектирование БД имеет итерационный характер. В процессе функционирования системы становится возможным измерение её реальных характеристик, выявление "узких" мест. И если система не отвечает предъявляемым к ней требованиям, то обычно она подвергается реорганизации, т.е. модификации первоначально созданного проекта.
Важным шагом на данном этапе необходимо проработать вопрос использования индексов.
В системах, поддерживающих язык SQL, индекс создаётся командой CREATE INDEX. Индексы повышают производительность запросов, которые выбирают относительно небольшое число строк из таблицы. Для определения целесообразности создания индекса нужно проанализировать запросы, обращённые к таблице, и распределение данных в индексируемых столбцах.
Система может воспользоваться индексом по определённому полю, если в запросе на значение этого поля накладывается условие, например:
SELECT * FROM authors WHERE name = 'Даль';
Но даже при наличии такой возможности система не всегда обращается к индексу. Очевидно, что если запрос выбирает больше половины записей отношения, то извлечение данных через индекс потребует больше времени, чем последовательная обработка данных. В подобных случаях использование индекса нецелесообразно.
Обращение к составному индексу возможно только в том случае, если в условиях выбора участвуют столбцы, представляющие собой лидирующую часть составного индекса. Например, если индекс строится по столбцам (X, Y, Z), то обращение к индексу будет происходить в тех случаях, когда в условии запроса участвуют столбцы XYZ, XY или X.
При создании индекса большое значение имеет понятие селективности. Селективность определяется процентом строк, имеющих одинаковое значение индексируемого столбца: чем выше этот процент, тем меньше селективность.
Выбор индексируемых столбцов определяется следующими соображениями:
-
В первую очередь выбираются столбцы, которые часто встречаются в критериях поиска.
-
Стоит индексировать столбцы, которые используются для соединения таблиц или являются внешними ключами. В последнем случае наличие индекса позволяет обновлять строки подчиненной таблицы без блокировки основной таблицы, когда происходит интенсивное конкурентное обновление связанных между собою таблиц.
-
Нецелесообразно индексировать столбцы с низкой селективностью. Если селективность столбца низкая, то индексирование проводится только в том случае, если выборка чаще производится по редко встречающимся значениям.
-
Не индексируются столбцы, которые часто обновляются, т.к. команды обновления ведут к потере времени на обновление индекса.
-
Не индексируются столбцы, которые часто используются как аргументы функций или выражений: как правило, такие функции не позволяют использовать индекс.
Необходимо произвести экспериментальные исследования, показывающие повышение (или снижение) быстродействия индексированной базы данных при выборке/добавлении/удалении данных. Исследования производить многократным выполнением повторяющихся запросов со случайными параметрами. На основании результатов исследования сделать выводы о необходимости индексирования тех или иных столбцов таблиц базы данных.
Этап 6. Разработка программного обеспечения.
Программное обеспечение разрабатывается на любом языке программирования с использованием программных средств, выбранных на этапе 2 (Microsoft Visual Studio, Borland/CodeGear Delphi/CBuilder, J2RE, PHP и т.п.). Разработанное ПО должно быть выполнено в форме дистрибутива.
Этап 7. Оформление контрольно-курсовой работы
Результаты выполнения контрольно-курсовой курсовой работы должны быть оформлены в виде пояснительной записки. Пояснительная записка должна быть оформлена в соответствии с требованиями ГОСТ 34.662.89.
Объем пояснительной записки контрольно-курсовой работы 20-30 стр. Работа сдается в напечатанном виде и в виде файлов на CD. Текстовая часть должна содержать ссылки на используемую литературу. Список используемой литературы приводится в соответствии с требованиями ГОСТ 34.662.89.
Текст должен быть отформатирован с параметрами: отступы — нулевые, красная строка — 1.27 см, межстрочный интервал — одинарный, выравнивание — по ширине. Текст должен содержать переносы. Все страницы текста должны содержать верхний колонтитул с фамилией и шифром группы исполнителя работы, а также нумерацию страниц с размещением над колонтитулом по центру. Размер основного шрифта — 14.
Пояснительная записка должна состоять из нескольких обязательных разделов, каждый из которых соответствует одному из этапов проектирования.
Файл пояснительной записки должен иметь имя, соответствующее шифру курсовой работы Шифр_группы_NN.doc (NN — номер студента в списке группы), файл Readme.txt должен содержать описание всех файлов работы.
Титульный лист приведен в приложении.
4. Библиографический список
|
