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

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

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

Северо-Кавказский государственный технический университет

Кафедра информационных систем и технологий

Проектирование сетевой базы данных для решения экономических задач «Гостиница»

Пояснительная записка к курсовому проекту

по дисциплине «Программирование в компьютерных сетях»

Ставрополь, 2011

СОДЕРЖАНИЕ

• ВВЕДЕНИЕ
• 1. ОБСЛЕДОВАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ
• 2. ПРОЕКТИРОВАНИЕ РЕЛЯЦИОННОЙ БАЗЫ ДАННЫХ
• 2.1 Описание входной информации
• 2.2 Описание выходной информации
• 2.3 Перечень сущностей
• 2.4 Перечень атрибутов
• 2.5 Инфологическое проектирование БД
• 2.6 Реляционная модель БД
• 2.7 Выбор ключей
• 3. ОРГАНИЗАЦИЯ ВЫБОРКИ ИНФОРМАЦИИ ИЗ БАЗЫ ДАННЫХ
• 4. РАЗРАБОТКА ПРЕДСТАВЛЕНИЙ ДЛЯ ОТОБРАЖЕНИЯ РЕЗУЛЬТАТОВ ВЫБОРКИ
• 5. ПРОЕКТИРОВАНИЕ ХРАНИМЫХ ПРОЦЕДУР
• 6. РАЗРАБОТКА МЕХАНИЗМОВ УПРАВЛЕНИЯ ДАННЫМИ В БАЗЕ ПРИ ПОМОЩИ ТРИГГЕРОВ
• 7. РАЗРАБОТКА ТЕХНОЛОГИЙ ДОСТУПА К БАЗЕ ДАННЫХ
• 8. ОРГАНИЗАЦИЯ ОБМЕНА ДАННЫМИ МЕЖДУ ПРИЛОЖЕНИЯМИ
• 9. ЭКОНОМИЧЕСКОЕ ОБОСНОВАНИЕ РЕЗУЛЬТАТОВ ВНЕДРЕНИЯ ПРОГРАММНОГО ПРОДУКТА
• 10. ТРЕБОВАНИЯ К ТЕХНИЧЕСКОМУ ОБЕСПЕЧЕНИЮ СЕРВЕРНОЙ
• 11. ИНСТРУКЦИЯ ПО ИСПОЛЬЗОВАНИЮ БД
• 11.1 Установка приложения
• 11.2 Запуск приложения
• 11.3 Работа с программой
• ЗАКЛЮЧЕНИЕ
• СПИСОК ЛИТЕРАТУРЫ3
• ПРИЛОЖЕНИЕ А3
• ВВЕДЕНИЕ
• В данном курсовом проекте была разработана база данных в СУБД Microsoft SQL Server 2005, программная оболочка в Microsoft Access для автоматизации процессов бронирования и оформления клиентов. Программа, работающая с БД, позволяет забронировать свободный номер, оформить клиента на заселение, а так же сформировать итоговые финансовые отчеты.
• Работать с БД будут администратор и пользователь, поэтому для защиты от несанкционированного доступа предусмотрена защита паролем входа в программу с разграничением прав доступа: пользователи имеют доступ не ко всей БД, а только к тем таблицам, которые им необходимы в связи с выполняемыми функциями. Администратор имеет доступ ко всей БД. В рамках данного курсового проекта была разработана сетевая реляционная база данных, описывающая предметную область «Поставка и реализация легковых автомобилей зарубежных производителей». Основное назначение спроектированной базы данных - предоставление удобства хранения информации о процессах поставки реализации легковых автомобилей. При проектировании была использована точка зрения администратора продаж, имеющему возможность оформлять заказы, продажу автомобилей, а так же добавлять информацию о моделях автомобилей. В качестве средств создания клиентской части базы данных был выбран Microsoft Visual Studio 2008, которая представляет собой высокоэффективную среду профессионального разработчика, которая свободно соединяет несколько технологий, предоставляющих разработчикам широкие возможности для создания Windows приложений. База данных была спроектирована с помощью Microsoft SQL Server 2005, являющегося надежным и стабильным средством создания баз данных.

1. ОБСЛЕДОВАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ

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

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

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

база данные гостиница access

2. ПРОЕКТИРОВАНИЕ РЕЛЯЦИОННОЙ БАЗЫ ДАННЫХ

2.1 Описание входной информации

В результате обследования предметной области при разработке базы данных «Гостиница» были использованы следующие входные данные:

- информация о состоянии номеров;

- информация о списке номеров;

- информация о клиентах;

- информация о сотрудниках;

- информация о стоимости номеров.

2.2 Описание выходной информации

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

2.3 Перечень сущностей

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

1. «Сотрудники» - представлена информация о сотрудниках.

2. «Должности» - содержит информацию о должностях сотрудников.

3. «Клиенты» - представлена информация о клиентах.

4. «Номера» - содержит список номеров.

5. «Категория» - представлена информация о номере.

6. «Состояние» - содержит информацию о состоянии номеров

2.4 Перечень атрибутов

Таблица 2.1 - Атрибуты отношения «Оформление»

Атрибут	Тип данных	Длина
КодОформления	Int	4
КодНомера	Int	4
КодКлиента	Int	4
Заезд	smalldatatime	4
Выезд	smalldatatime	4
Сумма	smallmoney	4
КодСотрудника	Int	4
Таблица 2.2 - Атрибуты отношения «Сотрудники»
Атрибут	Тип данных	Длина
КодСотрудника	Int	4
Фамилия	Char	15
Имя	Char	15
Отчество	Char	15
КодДолжности	Int	4
Пол	Int	4
Адрес	Char	20
Телефон	Int	4
Таблица 2.3 - Атрибуты отношения «Должности»
Атрибут	Тип данных	Длина
КодДолжности	Int	4
Должность	Char	15

Таблица 2.4 - Атрибуты отношения «Номер»

Атрибут	Тип данных	Длина
КодНомера	Int	4
КодКатегории	Int	4
КодСостояния	Int	4
Таблица 2.5 - Атрибуты отношения «Категория»
Атрибут	Тип данных	Длина
КодКатегории	Int	4
Категория	Char	15
КолМест	Int	4
КолКомнат	Int	4
Стоимость	Smallmoney	4

Таблица 2.6 - Атрибуты отношения «Состояние»

Атрибут	Тип данных	Длина
КодСостояния	Int	4
Состояние	Char	15

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

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

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

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

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

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

2.6 Реляционная модель БД

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

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

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

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

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

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

2.7 Выбор ключей

Использование ключей и индексов позволяет:

1. однозначно идентифицировать записи;

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

3. выполнять сортировку таблиц;

4. ускорять операции поиска в таблицах;

5. устанавливать связи между отдельными таблицами БД.

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

Таблица 2.9. Ключи

Таблица	Ключ	Тип ключа
Оформление	КодОформления КодКлиента КодНомера КодСотрудника	primary regular regular regular
Должности	КодДолжности	primary
Номер	КодНомера КодКатегории КодСостояния	primary regular regular
Категория	КодКатегории	primary
Состояние	КодСостояния	primary
Сотрудники	КодСотрудника КодДолжности	primary regular
Клиенты	КодКлиента	primary

3. ОРГАНИЗАЦИЯ ВЫБОРКИ ИНФОРМАЦИИ ИЗ БАЗЫ ДАННЫХ

Для организации выборки информации из базы данных в клиентском приложении были созданы следующие запросы:

1. Выборка данных о состоянии номеров из связанных таблиц:

SELECT dbo_Номер.КодНомера, dbo_Оформление.Заезд,

dbo_Оформление.Выезд, dbo_Категория.Категория, dbo_Оформление.Сумма, dbo_Сотрудники.Фамилия, dbo_Состояние.Состояние FROM dbo_Состояние INNER JOIN ((dbo_Категория INNER JOIN dbo_Номер ON dbo_Категория.КодКатегории = dbo_Номер.КодКатегории) INNER JOIN (dbo_Сотрудники INNER JOIN dbo_Оформление ON dbo_Сотрудники.КодСотрудника = dbo_Оформление.КодСотрудника) ON dbo_Номер.КодНомера = dbo_Оформление.КодНомера) ON ON dbo_Состояние.КодСостояния = dbo_Номер.КодСостояния

WHERE (((dbo_Состояние.Состояние)="Заселен"));

Результат представлен на рисунке 3.1.

Рисунок 3.1 - Выборка данных из связанных таблиц

2. Выборкаданных об имеющихся номерах с условием:

SELECT dbo_Номер.КодНомера, dbo_Категория.Категория, dbo_Категория.КолМест, dbo_Категория.Стоимость FROM dbo_Категория INNER JOIN dbo_Номер ON ON dbo_Категория.КодКатегории=dbo_Номер.КодКатегории WHERE (((dbo_Категория.Стоимость)>= 1500));

Результат представлен на рисунке 3.2.



Рисунок 3.2 - Выборка данных с использованием условия

3. Выборкаинформации по дате:

SELECTdbo_Номер.КодНомера, dbo_Оформление.Заезд, dbo_Оформление.Выезд, dbo_Категория.Категория, dbo_Оформление.Сумма, dbo_Сотрудники.Фамилия FROM (dbo_Категория INNER JOIN dbo_Номер ON dbo_Категория.КодКатегории=dbo_Номер. КодКатегории) INNER JOIN (dbo_Сотрудники INNER JOIN dbo_Оформление ON dbo_Сотрудники.КодСотрудника = dbo_Оформление.КодСотрудника) ON ON dbo_Номер.КодНомера = dbo_Оформление.КодНомера WHERE (((dbo_Оформление.Заезд) = #7/9/2007#));

Результат представлен на рисунке 3.3.

Рисунок 3.3 - Выборка данных по дате

4. РАЗРАБОТКА ПРЕДСТАВЛЕНИЙ ДЛЯ ОТОБРАЖЕНИЯ РЕЗУЛЬТАТОВ ВЫБОРКИ

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

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

Рисунок 4.1 - Представлении, отражающее информацию о сотрудниках

Рисунок 4.2 - Представление, отражающее информацию о номерах

5. ПРОЕКТИРОВАНИЕ ХРАНИМЫХ ПРОЦЕДУР

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

CREATE PROCEDURE New_Cena

(@id_Cena Real, @id_Sum Char )

AS

UPDATE Категория

SET Стоимость = Стоимость * @id_Cena

WHERE Стоимость = @id_Sum

Результат представлен на рисунке 5.1.

Рисунок 5.1 - Работа процедуры увеличения цены номера на определенный процент

6. РАЗРАБОТКА МЕХАНИЗМОВ УПРАВЛЕНИЯ ДАННЫМИ В БАЗЕ ПРИ ПОМОЩИ ТРИГГЕРОВ

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

Триггеры в созданном приложении отвечают за «корректное» удаление «клиентов». Такая ситуация может иметь место в случае, когда один из клиентов покинет гостиницу и информация о нем уже не будет нужна. Чтобы избежать потери данных о произведенных операциях или случаев, когда данные в базе теряют актуальность в результате потери принадлежности, и используются триггеры. Хотя защита от такого удаления предусмотрена программно, тем не менее, реализовано это и с помощью триггеров.

CREATE TRIGGER cascade_del_trigger

ON [dbo].[Оформление] FOR DELETE

AS

IF @@ROWCOUNT = 0

RETURN

DELETE КодКлиента

FROM Оформление, Клиенты

WHERE Оформление.КодКлиента = Клиенты.КодКлиента

IF @@ERROR ! = 0

BEGIN

PRINT 'Error occurred during related tables' ROLLBACK TRAN

END

RETURN

При удалении клиента из таблицы клиенты (рисунок 6.1) оформления номеров клиент удаляется автоматически (рисунок 6.2)

Рисунок 6.1 - Удален клиент Синенко из таблицы «Клиенты»

Рисунок 6.2 - Из таблицы «Оформление» автоматически удалён клиент Синенко

7. РАЗРАБОТКА ТЕХНОЛОГИЙ ДОСТУПА К БАЗЕ ДАННЫХ

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

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

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

При запуске клиентского приложения требуется ввести пароль и логин пользователя. Таким образом обеспечивается безопасность БД от несанкционированного доступа на клиентском уровне.

8. ОРГАНИЗАЦИЯ ОБМЕНА ДАННЫМИ МЕЖДУ ПРИЛОЖЕНИЯМИ

Управляемый провайдеры (managed procider) в ADO.NET - это аналог провайдеры OLE DB в классическом ADO. Другими словами, управляемый провайдер - это шлюз к хранилищу данных (например, на сервере баз данных), при помощи которого можно произвести загрузку данных из этого внешнего хранилища в объект DataSet. Существуют 2 наиболее распространенных управляемых провайдера. Первый из них - это OLE DB, который реализуется при помощи типов, определенных в пространстве имен System.Data.OleDb. Провайдер OleDb позволяет нам обращаться к данным, расположенным в любом хранилище, к которому можно подключиться по протоколу OLE DB. таким образом, аналогично классическому ADO, можно использовать в ADO.NET управляемый провайдер OLE DB для доступа, например, к базам данных SQL Server, MS Access и Oracle, однако поскольку при этом типы из пространства имен System.Data.OleDb должны взаимодействовать с обычным (не .NET) кодом провайдера OLE DB, то при таком обращении будет производиться множество преобразований вызовов .NET в вызовы СОМ, что в некоторых ситуациях может привести к падению производительности. Второй управляемый провайдер - провайдер SQL - предлагает уже прямой доступ к хранилищам данных, при котором производительность будет максимальной, однако с его помощью можно обращаться только к базам данных MS SQL Server. Типы, используемые провайдером SQL, содержатся в пространстве имен System.Data.Sqlclietn. Функциональные возможности обоих управляемых провайдеров практически одинаковы. Главное различие между провайдерами заключается в том, что провайдер SQL не использует классические протоколы OLE DB или ADO и за счет этого обеспечивает значительных выигрыш в производительности.

9. ЭКОНОМИЧЕСКОЕ ОБОСНОВАНИЕ РЕЗУЛЬТАТОВ ВНЕДРЕНИЯ ПРОГРАММНОГО ПРОДУКТА

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

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

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

Рассчитаем экономический эффект от использования программного продукта за период внедрения.

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

Э_у = 3_р - 3_А - экономия от замены ручной обработки информации на автоматизированную обработку.

З_р = О_н?Ц?Г_д/Н_р - затраты на ручную обработку информации, руб. 0Н=1500?25?80=1,9 Мбайт - объем информации, обрабатываемой вручную (1500 страниц в неделю).

Ц = 8000/160 = 50 - стоимость одного часа при окладе 8000 рублей в месяц и 40 часовой рабочей недели.

Г_д = 1,2 - коэффициент, учитывающий дополнительные затраты времени на логические операции при ручной обработке информации. Нр=15?25?80=0,029 Мбайт/час - норма выработки: 15 страниц в час (80 символов на 25 строк).

З_р = 5159,49

3_А = t_a?Ц_м+t₀?(Ц_м+Ц_о) - затраты на автоматизированную обработку информации.

t_A = 2 (час) - время автоматической обработки.

Ц_м = 3 (руб/час) - стоимость одного часа машинного времени.

t₀ = 8 - время работы оператора.

Ц₀ = 50 - стоимость одного часа работы оператора.

3_А = 380

Э_у = 5159,49-3 80 = 4779,49

Э_Г = Э_У-3_К?5/365

З_к = 299827,2727 - калькуляция расходов на разработку БД.

Э_г = 4779,49-4107,23=672,26

Э_Р = (Э_Г?0,4)/3_К

Э_р = 0,22 - эффективность разработки базы данных.

10. ТРЕБОВАНИЯ К ТЕХНИЧЕСКОМУ ОБЕСПЕЧЕНИЮ СЕРВЕРНОЙ

Требования к техническому обеспечению серверной части:

- IBM-совместимый компьютер с тактовой частотой процессора не менее 166 MHz;

- ОЗУ 64 MB (рекомендуется 128 MB);

- не менее 400 MB свободного дискового пространства;

- видеокарта с поддержкой разрешения 800x600;

- монитор типа SVGA;

- ОС Microsoft Windows 2000/ХР/2003/Vista/7;

- CD-ROM/DVD-ROM.

Требования к техническому обеспечению клиентской части:

- IBM-совместимый компьютер с тактовой частотой процессора не менее 400 MHz;

- ОЗУ 64 MB (рекомендуется 128 MB);

- не менее 50 MB свободного дискового пространства;

- видеокарта с поддержкой разрешения 800x600;

- монитор типа SVGA;

- CD-ROM/DVD-ROM;

- ОС Microsoft Windows 2000/ХР;

- .NET Framework 2.0.

11. ИНСТРУКЦИЯ ПО ИСПОЛЬЗОВАНИЮ БД

11.1 Установка приложения

Для установки приложения «Гостиница» на персональный компьютер клиента необходимо скопировать папку с приложением на жесткий диск и запустить файл My_db.mdb двойным щелчком мыши.

11.2 Запуск приложения

При запуске приложения появится окно, в котором требуется ввести логин и пароль пользователя для дальнейшей работы с приложением (Рисунок 11.1).

Рисунок 11.1 - Окно входа в систему приложения

11.3 Работа с программой

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

Ниже приведены формы, с которыми возможна работа, при нажатии на соответствующие кнопки (Рисунок 11.2 - 11.9)



Рисунок 11.2 - Форма «Сотрудники»

Рисунок 11.4 - Форма «Список номеров»

Рисунок 11.9 - Отчет «Финансовый отчет»

ЗАКЛЮЧЕНИЕ

Реляционная модель данных в настоящее время приобрела наибольшую популярность и практически все современные СУБД ориентированы именно на такое представление данных.

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

В данном проекте была создана реляционная база данных «Гостиница», разработанная с помощью приложения Microsoft Access 2010.

СПИСОК ЛИТЕРАТУРЫ

1. Карпова Т.С. Базы данных. Модели, разработка, реализация / СПб.: Питер, 2002. - 304 с.

2. Хомоненко А.Д., Цыганков В.М., Мальцев М.Г. Базы данных. Учебник для ВУЗов / под ред. проф. А.Д. Хомоненко // СПб.: КОРОНА принт, 2000. - 416 с.

3. Корнеев В.В. и др. Базы данных. Интеллектуальная обработка информации // М.: Нолидж, 2000. - 352 с.

4. Дроздова В.И., Крахоткина Е.В., Федоров С.О. Базы данных. Методические указания к лабораторным работам для студентов специальности 351400. Ставрополь, СевКавГТИ, 2002.

5. Дроздова В.И., Крахоткина Е.В. Методические указания к выполнению курсового проекта по дисциплине «Базы данных» для студентов специальности 351400. Ставрополь, СевКавГТУ, 2004.

6. Каратыгин С.А., Тихонов А.Ф., Тихонова Л.Н. Visual FoxPro 6.0 // М.: Бином, 1999-784 с.

7. Хансен Г., Хансен Д. Базы данных. Разработка и управление / М.: Бином, 1999-704 с.

8. Баженова И.Ю. Visual Fox Pro 5.0//М.: Диалог МИФИ, 1997 - 320 с.

9. Глушаков С.В., Ломотько Д.В. Базы данных. Учебный курс // Харьков: Фолио; Ростов н/Д: Феникс; Киев: Абрис, 2000. - 504 с.

ПРИЛОЖЕНИЕ А

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