База данных "Драматический театр"

Размещено на http://www.allbest.ru/

Содержание

Введение

Глава 1. Теоретические аспекты проектирования базы данных

1.1 Понятие СУБД и БД

1.2 Описание предметной области «Драматический театр»

1.3 Инфологическое проектирование

1.4 Выбор СУБД

1.5 Логическое проектирование БД

Глава 2. Проектирование базы данных «драматический театр»

2.1 Разработка проекта и базы данных

2.1.1 Создание таблиц

2.1.2 Определение условий целостности

2.2 Создание запросов

2.3 Создание форм

2.4 Создание отчетов

2.5 Создание меню базы данных

2.6 Создание справочной системы

2.7 Создание инсталляционного пакета

Заключение

Список литературы

база целостность инсталляционный таблица



Введение

Мир искусства является самым драгоценным, что есть в нашем мире. Искусство не знает поры и времени. И искусство всегда актуально для его ценителей.

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

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

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

Для достижения цели были поставлены следующие задачи:

Описать поставленной задачи;

Выполнить инфологическое, логическое проектирование;

Выбрать СУБД;

Спроектировать базу данных с необходимыми объектами;

Создать меню приложения и инсталляционный пакет;

Разработать систему оперативной справки;

Разработать инсталляционный пакет.

Предметом работы является разработка базы данных для предметной области «Драматический театр».

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

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



Глава 1. Теоретические аспекты проектирования базы данных

1.1 Понятие СУБД и БД

Банк данных (БнД) - это система специальным образом организованных данных (баз данных), программных, технических, языковых, организационно-методических средств, предназначенных для обеспечения централизованного накопления и коллективного многоцелевого использования данных [4,с.76].

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

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

База данных (БД) - это специальным образом организованные данные, т.е. системы взаимосвязанных данных, единство и целостность которых поддерживается специальными программными средствами [3,с.98].

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

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

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

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

Для функционирования БД необходимо наличие специальных языковых и программных средств (называемых СУБД), облегчающих для пользователей выполнение всех операций, связанных с организацией хранения данных, их корректировки и доступа к ним. [3, с.34]

Классификация БД.

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

2.По характеру организации данных БД могут быть разделены на неструктурированные, частично структурированные и структурированные.

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

Полю соответствует наименьшая семантическая единица информации; совокупность полей или/и иных, более сложных информационных единиц, если они допустимы в конкретной СУБД, образуют запись, а множество однотипных записей представляют файл базы данных. В последнее время большинство СУБД в явном виде поддерживают и уровень базы данных, как совокупности взаимосвязанных файлов БД. [3, с.48].

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

Графическим представлением иерархической модели является граф типа «дерево». В такой модели имеется одна вершина - корень дерева, являющаяся входом в структуру. Каждая вершина, отличная от корня, может иметь только одну исходную вершину и, в общем случае, сколько угодно порожденных вершин.

Графическое представление сетевой модели представляет собой граф типа «сеть». Входом в такую структуру может являться любая вершина. Каждая вершина может иметь как несколько порожденных, так и несколько исходных вершин. Между парой вершин может быть объявлено несколько связей. Подавляющее большинство СУБД поддерживает простые сетевые структуры, т. е. между каждой парой типов записей поддерживается отношение 1:М.

3. По типу хранимой информации БД делятся на: документальные, фактографические и лексикографические.

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

Персональная база данных - это база данных, предназначенная для локального использования одним пользователем. Локальные БД могут создаваться каждым пользователем самостоятельно, а могут извлекаться из общей БД [6, c.87]

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

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

Системы управления базами данных (СУБД) - это комплекс языковых и программных средств, предназначенный для создания, ведения и совместного использования БД многими пользователями. Обычно СУБД различают по используемой модели данных. Так, СУБД, основанные на использовании реляционной модели данных, называют реляционными СУБД [5, с.67].

1.По языкам общения СУБД делятся на открытые, замкнутые и смешанные.

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

2.По числу уровней в архитектуре различают одноуровневые, двухуровневые, трехуровневые системы.

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

4.По сфере возможного применения различают универсальные и специализированные, обычно проблемно-ориентированные СУБД.

5.По «мощности» СУБД делятся на «настольные» и «корпоративные». Характерными чертами настольных СУБД являются сравнительно невысокие требования к техническим средствам, ориентация на конечного пользователя, низкая стоимость.

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

Наиболее известными из корпоративных СУБД являются Oracle , Informix , Sybase , MS SQL Server, Progress и некоторые другие.

Существует разделение СУБД по поколениям:

1 поколение - основано на иерархической и сетевой модели.

2 поколение - Реляционные системы.

3 поколение - СУБД должны поддерживать сложные структуры данных и более развитые средства обеспечения целостности данных, отвечать требованиям, предъявляемым к открытым системам.

1.2 Описание предметной области «Драматический театр»

Драматический театр -- один из основных видов театра, наряду с оперным и балетным, театром кукол и пантомимой [3, с.67].

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

Ежедневно театр проводит несколько спектаклей, его посещают тысячи зрителей.

Драматический театр как система должен состоять из таких частей как:

представления;

работники театра;

постановки(спектакли);

театральные залы;

билеты на спектакль;

актеры (труппы);

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

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

1.3 Инфологическое проектирование

Инфологическое (концептуальное) проектирование - это построение семантической модели предметной области, то есть информационной модели наиболее высокого уровня абстракции. Такая модель создается без ориентации на какую-либо конкретную СУБД модель данных. Термины «семантическая модель», «концептуальная модель» и «инфологическая модель» являются синонимами. Кроме того, в этом контексте равноправно могут использоваться слова «модель базы данных» и «модель предметной области» (например, «концептуальная модель базы данных» и «концептуальная модель предметной области»), поскольку такая модель является как образом реальности, так и образом проектируемой базы данных для этой реальности.

Чаще всего концептуальная модель базы данных включает в себя:

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

Конкретный вид и содержание концептуальной модели базы данных определяется выбранным для этого формальным аппаратом. Обычно используются графические нотации, подобные ER-диаграмм [7, с. 59].

Модель «сущность-связь» (англ.“Entity-Relationship model”), или ER-модель, предложенная П. Ченом в 1976 г., является наиболее известным представителем класса семантических (концептуальных, инфологических) моделей предметной области. ER-модель обычно представляется в графической форме, с использованием оригинальной нотации П. Чена, называемой ER-диаграмма, либо с использованием других графических нотаций (Crow's Foot, Information Engineering и др.).

Основные преимущества ER-моделей:

-наглядность;

-модели позволяют проектировать базы данных с большим количеством объектов и атрибутов;

ER-модели реализованы во многих системах автоматизированного проектирования баз данных (например, ERWin).

Основные элементы ER-моделей:

-объекты (сущности);

-атрибуты объектов;

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

Сущность -- объект предметной области, имеющий атрибуты.

Связь между сущностями характеризуется:

типом связи (1:1, 1:N, N:М);

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

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

Отобразим сущность ЗАЛЫ в виде ER- диаграммы (таблица 1.1) такие атрибуты как: код зала, название будут динамическими, а описание, вместительность и количество рядов- статическими.



Таблица 1.1 - «Залы»

Следующей отобразим инфологическую модель сущности СЕКТОРЫ ЗАЛА (таб.1.2). В данной диаграмме значение статических переменных будут принимать атрибуты: начальный ряд, конечный ряд, конечный сектор, все остальные- динамические переменные.

Таблица 1.2 - «Секторы зала»

Так же выделим как отдельную сущность МЕСТА (таб. 1.3), все атрибуты, которой будут статическими.

Таблица 1.3 - «Места»



В следующей ER- диаграмме (таб. 1.4) рассмотрим атрибуты сущности БИЛЕТЫ, переменные цена, код спектакля, статус являются динамическими, атрибуты дата сеанса, код билета, время сеанса, серия-статические.

Таблица 1.4 - «Билеты»

Так же добавим сущность СПЕКТАКЛИ (таб. 1.5), в которой все переменные -статистические.

Таблица 1.5 - «Спектакли»

Последней ER-диаграммой будет сущность СОТРУДНИКИ (таб. 1.6). Все переменные, кроме обязанностей, кода и паспортных данных будут динамическими.



Таблица 1.6 - «Сотрудники»

Связи между таблицами установим следующими:

Таблицы «Залы» и «Секторы зала» связь- один ко многим(1:М) ;

Таблицы «Секторы зала» и «Места» связь -один ко многим (1:М);

Таблицы «Места» и «Билеты» связь -один ко многим(1:М);

Таблицы «Спектакли» и «Билеты» связь многие ко одному (М:1);

Таблицы «Спектакли» и «Сотрудники» связь один ко многим (1:М);

1.4 Выбор СУБД

Существует множество видов СУБД поэтому перед выбором одной определенной следует рассмотреть несколько систем, разобрать их характеристики, достоинства и недостатки.[8, с.96]

СУБД Oracle

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

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

Встраивание в СУБД Oracle JavaVM, полномасштабная поддержка серверных технологий (Java Server Pages, Java-сервлеты, модули Enterprise JavaBeans, интерфейсы прикладного программирования CORBA), привело к тому, что Oracle на сегодняшний день де-факто является стандартом СУБД для Internet.

Еще одной составляющей успеха СУБД Oracle является многоплатформенность, так как она поставляется практически для всех существующих на сегодня операционных систем. Работая под Sun Solaris, Linux, Windows или на другой операционной системе с продуктами Oracle не будет возникать никаких проблем в работе. СУБД Oracle одинаково хорошо работает на любой платформе. Таким образом, компаниям, начинающим работу с продуктами Oracle не приходится менять уже сложившееся сетевое окружение. Существует лишь небольшое количество отличий при работе с СУБД, обусловленных особенностями той или иной операционной системы. В целом же это всегда та же самая безопасная, надежная и удобная СУБД Oracle.

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

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

СУБД Oracle поставляется в четырех вариантах Oracle Database Enterprise Edition, Oracle Database Standard Edition, Oracle Database Personal Edition и совсем облегченный мобильный вариант, предназначенный в первую очередь для laptop-ов. При этом все варианты сервера Oracle имеют в своем основании один и тот же код и функционально идентичны за исключением некоторых опций, которые например, могут быть доступны только для Oracle Database Enterprise Edition и не поставляться с другими вариантами СУБД [2, с.67].

СУБД MC ACCESS

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

Необходимость программировать всегда сдерживала широкое внедрение баз данных в малом бизнесе.

Положение изменилось с появлением в составе пакета Microsoft Office системы управления базами данных Access. С помощью Access 9x обычные пользователи получили удобное средство для создания и эксплуатации достаточно мощных баз данных без необходимости что-либо программировать. В то же время работа с Access 9x не исключает возможности программирования. При желании систему можно развивать и настраивать собственными силами. Для этого надо владеть основами программирования на языке Visual Basic.

Еще одним дополнительным достоинством Access 9x является инсценированность этой программы с Excel 9x, Word 9x и другими программами пакета Office 9x. Данные, созданные в разных приложениях, входящих в этот пакет, легко импортируются и экспортируются из одного приложения в другое [8, с.56].

СУБД My SQL Server

SQL - это сокращение от Structured Query Language (структурированный язык запросов) [5, c.90].

SQL создан для работы с реляционными базами данных.

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

My SQL Server соответствует спецификации ANSI 92 SQL, является собственностью компании Sun Microsystems, осуществляющей разработку и поддержку приложения.

Распространяется под GNU General Public License и под собственной коммерческой лицензией, на выбор.

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

Основные положительные стороны My SQL Server:

1. Многопоточность. Поддержка нескольких одновременных запросов.

2. Оптимизация связей с присоединением многих данных за один проход.

3. Записи фиксированной и переменной длины.

4. ODBC драйвер в комплекте с исходником

5. Гибкая система привилегий и паролей.

6. До 16 ключей в таблице. Каждый ключ может иметь до 15 полей.

7. Поддержка ключевых полей и специальных полей в операторе .

8. Поддержка чисел длинной от 1 до 4 байт (ints, float, double, fixed), строк переменной длины и меток времени.

9. Интерфейс с языками C и Рerl.

10. Основанная на потоках, быстрая система памяти.

11. Утилита проверки и ремонта таблицы (isamchk).

12. Все данные хранятся в формате ISO8859_1.

13. Все операции работы со строками не обращают внимания на регистр символов в обрабатываемых строках.

14. Псевдонимы применимы как к таблицам, так и к отдельным колонкам в таблице.

15. Все поля имеют значение по умолчанию. можно использовать на любом подмножестве полей.

16. Легкость управления таблицей, включая добавление и удаление ключей и полей [7, c.85].

My SQL Server ориентирована на большое количество платформ:

AIX, BSDi, FreeBSD, HP-UX, GNU/Linux, Mac OS X, NetBSD, OpenBSD, OS/2 Warp, SGI IRIX, Solaris, SunOS, SCO OpenServer, SCO UnixWare, Tru64, Windows 95, Windows 98, Windows NT, Windows 2000, Windows XP, Windows Server 2003, WinCE, Windows Vista и Windows 7.

Существует также порт My SQL Server к OpenVMS.

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

My SQL Server имеет API для языков Delphi, C, C++, Эйфель, Java, Лисп, Perl, PHP, Python, Ruby, Smalltalk и Tcl, библиотеки для языков платформы .NET, а также обеспечивает поддержку для ODBC посредством ODBC-драйвера MyODBC.

СУБД FoxPro

Для выполнения данной курсовой работы все же выберем СУБД FoxPro.

FoxPro может создавать и клиент-серверные БД, однако в этой области VFoxPro значительно уступает большинству из известных серверов БД.

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

Все вышесказанное относится к VFoxPro как средству разработки баз данных, однако на нем не представляется интересным создавать приложения не связанные с БД, хотя сам FoxPro является языком самодостаточным. Это связано с тем, что с VFoxPro поставляется очень убогий класс для работы с визуальными компонентами, а исходный код этого класса закрыт. Поэтому разработчик ограничен в возможностях "украшать" свою программу. Следующее, в FoxPro не происходит объявления типа переменных, это лишает возможности контролировать правильность обращения к переменной и, главное, под переменную отводится максимальное кол-во памяти, поэтому программы написанные на VFoxPro очень ресурсоемкие. Большой недостаток VFoxPro - это крайне слабый конструктор отчетов, крайне осложняющий разработку приложения. Для работы программы, созданной на VFoxPro, необходимы библиотеки поддержки, что увеличивает размер поставляемой программы еще, примерно, на 4 Mb. Есть еще более мелкие недостатки.

Основными недостатками являются: большие требования к памяти, программами созданными на VFoxPro и слабые возможности по работе с визуальными компонентами.

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



1.5 Логическое проектирование БД

Логическое проектирование - это процесс конструирования общей информационной модели предприятия на основе отдельных моделей данных пользователей, которая является независимой от особенностей реально используемой СУБД и других физических условий [5, c.78].

Первым этапом логического проектирования

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

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

3. Проверка модели с помощью правил нормализации.

4. Проверка модели в отношении транзакций пользователей.

5. Создание диаграммы сущность-связь.

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

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

Второй этап проектирования:

1. Слияние локальных моделей в единую глобальную модель данных (анализ имен сущностей и связей ,PK).

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

3. Проверка возможностей расширения модели в будущем.

4. Создание окончательного варианта диаграммы сущность-связь

5. Обсуждение глобальной модели данных с пользователем.

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

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

Одним из важных разделов создания базы данных с помощью любой СУБД является нормализация данных.

Нормальная форма -- свойство отношения в реляционной модели данных, характеризующее его с точки зрения избыточности, потенциально приводящей к логически ошибочным результатам выборки или изменения данных. Нормальная форма определяется как совокупность требований, которым должно удовлетворять отношение [7, c.94].

Процесс преобразования отношений базы данных к виду, отвечающему нормальным формам, называется нормализацией. Нормализация предназначена для приведения структуры БД к виду, обеспечивающему минимальную логическую избыточность, и не имеет целью уменьшение или увеличение производительности работы или же уменьшение или увеличение физического объёма базы данных [1, c.78]. Конечной целью нормализации является уменьшение потенциальной противоречивости хранимой в базе данных информации. Как отмечает К. Дейт [2, c.45], общее назначение процесса нормализации заключается в следующем:

- исключение некоторых типов избыточности;

- устранение некоторых аномалий обновления;

- разработка проекта базы данных, который является достаточно «качественным» представлением реального мира, интуитивно понятен и может служить хорошей основой для последующего расширения;

- упрощение процедуры применения необходимых ограничений целостности.

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

При том, что идеи нормализации весьма полезны для проектирования баз данных, они отнюдь не являются универсальным или исчерпывающим средством повышения качества проекта БД. Это связано с тем, что существует слишком большое разнообразие возможных ошибок и недостатков в структуре БД, которые нормализацией не устраняются. Несмотря на эти рассуждения, теория нормализации является очень ценным достижением реляционной теории и практики, поскольку она даёт научно строгие и обоснованные критерии качества проекта БД и формальные методы для усовершенствования этого качества, которые предлагаются в других моделях данных. Более того, можно утверждать, что во всей сфере информационных технологий практически отсутствуют методы оценки и улучшения проектных решений, сопоставимые с теорией нормализации реляционных баз данных по уровню формальной строгости [3, c.34].

Существует последовательность нормализации данных.

Первая нормальная форма (1NF)

Переменная отношения находится в первой нормальной форме (1НФ) тогда и только тогда, когда в любом допустимом значении отношения каждый его кортеж содержит только одно значение для каждого из атрибутов [7, c.89].

В реляционной модели отношение всегда находится в первой нормальной форме по определению понятия отношение. Что же касается различных таблиц, то они могут не быть правильными представлениями отношений и, соответственно, могут не находиться в 1НФ.

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

Таблица 1.7 - «Данные в первой нормальной форме».

Код зала
Вместительность рядов
Количество рядов
Код сектора зала
Название залов
Код места
Номер ряда
Код спектакля
Название спектакля
Сюжет
Длительность спектакля
Код билета
Цена билета
Время представления
Серия билета
Номер билета
Статус билета
Время представления
Код сотрудника
ФИО сотрудников
Паспортные данные
Адрес
Телефон
Должность

Вторая нормальная форма (2NF)

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

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

Таблица 1.8 - «Залы»

!Код_зала
Название
Описание
Вместительность
Количество_ рядов

Таблица 1.9 - «Секторы зала»

! Код_сектора_зала
Название
Начальный _ряд
Номер_ряда
Номер_места
Конечный_ряд

Таблица 1.10 - «Спектакли»

! Код_спектакля
Название
Длительность
Сюжет

Таблица 1.11 - «Билеты»

! Код_билета
Цена
! Код_спектакля
Цена
Дата_представления
Время_представления
Серия
Номер_билета
Статус



Таблица 1.12 - «Сотрудники»

! Код_спектакля
ФИО
Паспортные_данные
Адрес
Телефон
Должность
Обязанности

Обратим внимание, что данные таблицы 1.9 можно привести к 3НФ, поэтому нормализируем данные путем устранения транзитивности

Таблица 1.13 - «Секторы зала»

! Код_сектора_зала
Название
Начальный_ряд
Конечный_ряд
! Код_зала

Таблица 1.14 - «Места»

! Код_места
Номер _ряда
Номер_места
! Код_сектора

Сущности находятся в третей нормальной форме, об этом говорит отсутствие транзитивных зависимостей.

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



Глава 2. Проектирование базы данных «драматический театр»

2.1 Разработка проекта и базы данных

Перед началом работы установим СУБД FoxPro 9.0. Условно физическое проектирование можно разделить на несколько пунктов.

Чтоб начать создание проекта выберем File>New>Project>New file (рис.2.1).

Рис. 2.1.Окно создания нового проекта.

Затем дадим имя DRAM_TEATR и укажем путь сохранения (рис. 2.2).

Рисунок 2.2. Имя и путь сохранения проекта



Перед нами появится новое окно проекта, выберем создание новой базы данных (рис 2.3).

Рисунок 2.3. Окно нового проекта базы данных

Выберем Database>Add>New Database (рис 2.4).

Рис. 2.4. Создание новой базы данных

2.1.1 Создание таблиц

Главным элементом любой базы данных не зависимо от выбранной СУБД являются таблицы.

Таблицы в базах данных предназначены:

1.для хранения данных базы;

2.для отбора и обработки данных базы;

3.для ввода данных базы и их просмотра;

4.для автоматического выполнения группы команд;

5.для выполнения сложных программных действий.

Чтоб создать таблицу выберем Database>New Table (рис. 2.5).



Рис. 2.5. Создание новой таблицы

Аналогично проекту дадим таблице имя и укажем путь сохранения, с помощью кнопки Modify откроем ее в режиме конструктора (рис.2.6).

Рис. 2.6. Режим конструктора таблицы

Заполним в режиме конструктора таблицу «Места» (рис. 2.7), с помощью поля Caption зададим значение полей на русском языке.

Рис. 2.7.Таблица «Места» в режиме конструктора.

Аналогично создадим и заполним остальные таблицы и откроем в режиме просмотра.



Функции Modify позволяет редактировать данные в режиме конструктора, Caption-переводить значение полей на русский язык, Run-запуск, режим просмотра данных (рис. 2.8).

Рис. 2.8.Режим таблицы.

2.1.2 Определение условий целостности

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

Рис. 2. 9. Окно конструктора базы данных

И в окне целостности связей выберем каскадное обновление данных (рис. 2.10)

Рис. 2.10 Окно целостности данных



2.2 Создание запросов

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

Чтоб создать запрос(Query) выберем File>New>Query>New file, укажем имя и таблицу, к которой относится запрос (рис. 2.11).

Рис. 2.11.Создание запроса информации о спектаклях.

Аналогично создадим еще два запроса, выполним и запустим в режиме просмотра.

2.3 Создание форм

Для создания формы выберем File>New>Form>New form, укажем имя и таблицу по которой она создается.

Появится пустое окно формы (рис. 2.12).



Рис. 2.12. Окно формы

Укажем какие данные мы перемещаем для использования в форме (рис.2.13).

Рис.2.13.Создание формы авторизации.

Рис. 2.14.Форма авторизации.

Аналогично создадим форму данных по сотрудникам и спектаклям.

2.4 Создание отчетов

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

Для создания отчета выберем File>New>Report>New report.

Укажем данные, которые поместим в отчет (рис 2.15).

Рис. 2.15Создание отчета.

Рис. 2.16.Создание отчетов.

Таким же образом создадим еще два отчета.

2.5 Создание меню базы данных

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

Выберем File>New>Menu



Рис. 2.16.Создание меню.

Рис. 2.17.Меню в режиме конструктора.

2.6 Создание справочной системы

Для создания справочной системы будем использовать HTML Work Shop.

Для начала создадим нужное нам количество html-документов, которые в последствии поместим в проект и содержание.

Запустим приложение и создадим новый проект, а так же содержание(Table of Contents), для этого выберем File>New>Project>Table of Contents (рис 2.18).

Рис. 2.18.Создание нового проекта справочной системы.



Затем укажем имя и путь сохранения справочной системы, в следующем окне укажем все элементы из которых будет состоять справочная система: содержание, указатель, все html-файлы (рис 2. 19) .

Рис.2.19.Имя проекта и его элементы.

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

Рис.2.20.Элементы справочной системы

После создание проекта создадим новое содержание.

Выберем Contents>Create new Table of Contents>Ok (рис 2. 21).

.

Рис. 2.21.Создание содержания

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

Рисунок 2.22.Добавление файла.

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

Рис.. 2.23.Структура содержания.

Таким же образом добавим в структуру Указатель и поиск по разделам. Для этого выберем Index>New>Create new index>Ok.

Откомпилируем проект и запустим справочную систему.

2.7 Создание инсталляционного пакета

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



Рис. 2. 24. Создание инсталляционного пакета

Укажем путь сохранение инсталяционного пакета в пункте “Вывод” (рис.2.25).

Рис. 2.25. Путь сохранения инсталляционного пакета.

В процессе проектирования была создана база данных «Драматический театр». Было выполнено более углубленное исследование предметной области, создана многотабличная база данных, заполнены таблицы, создан ряд форм, запросов, отчетов по теме. К работе прикреплены справочная система и инсталляционный пакет.



Заключение

В ходе выполнения курсовой работы получены такие результаты:

По завершению написания курсовой работы была выведена методическая литература для проектирования базы данных «Драматический театр».

Была проанализирована предметная область «Драматический театр».

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

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

Для ввода, редактирования, удаления и поиска данных было роздано три формы, три отче та и три запроса.

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



Список литературы

1. Ребекка М. Райордан Основы баз данных 2001г.

2. Трифонова Н.А., Прозорова С.С. Office для студента. 2004г.

3. Ролланд Ф.Д. Основные концепции баз данных. 2002г.

4. Карпова Т. Базы данных: модели, разработка, реализация, 2001.

5. Айтхожаева Е. Ж. «Системы баз данных», учебник, 2001 г.

6. Дейт К. Дж. «Введение в системы баз данных», 7-е издание - М.: Издательский дом «Вильямс», 2002 г.

7. Каратыгин С. А., Тихонов А. Ф., Тихонова Л. Н. «Visual FoxPro» 7. - М.: Бином - Пресс, 2003 г.

8. В.Г. Оливер «Сетевые сети операционной системы», - Питер 2001 г.

9. Колин А. «Введение в операционную систему», - Мир, 1975 г.

10. «Современные операционные системы», Э. Тененбау, 2002 г.

11. Windows 98. Учебный курс. СПБ.: Питер, 1999 г.

12. Стоцкий Ю. Самоучитель Microsoft Office 2000 СПб.: Питер.: 1999 г.

13. Винтер П. Microsoft Word 97г.

14. Visual FoxPro Server справочник под. Ред. Ю. Колесникова.- СПб.: Питер, 1999г.

15. Рейзнер Т. Самоучитель FoxPro. - СПб.: Питер, 1999 г.

16. Специальная информатика. Учебное пособие. Универсальный курс, Симонович. С. Г. Евсеев, А.Алексеев 2004 г.

Размещено на Allbest.ru

...