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

Автор: Пользователь скрыл имя, 07 Апреля 2011 в 18:37, курсовая работа

Краткое описание

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

Оглавление

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

Файлы: 1 файл

Курсовая работа.doc

— 427.50 Кб (Скачать)
 
 

      Таблица: Проданные места

Имя поля Тип данных Обязательное  поле Индексированное поле Условие на значение
КодРейса Числовой Да Да(совпадения допускаются)  
Дата Дата/Время Да  
Место Числовой Да Нет >0
Цена Денежный Да Нет  
 

      Таблица: РасписаниеРейсов

Имя поля Тип данных Обязательное  поле Индексированное поле
КодРейса Счетчик Да Да(совпадения не допускаются)
КодМарш Числовой Да Да(совпадения допускаются)
ДеньНедели Числовой Да Нет
ВрОтпр Текстовый Да Нет
ВрПриб Текстовый Да Нет
 

      Таблица: Самолеты

Имя поля Тип данных Обязательное  поле Индексированное поле Условие на значение
НомСам Текстовый Да Да(допускаются  не совпадения)  
Поступл Дата/Время Да Нет  
ТребРемонт Логический Да Нет  
ТипСам Текстовый Да Нет  
КоличМест Числовой Да Нет >10
 

      Таблица: Сведения о летчиках

Имя поля Тип данных Обязательное  поле Индексированное поле Условие на значение
КодЛетчика Счетчик Да Да(совпадения не допускаются)  
Фамилия Текстовый Да Нет  
Имя Текстовый Да Нет  
Отчество Текстовый Да Нет  
Паспорт Текстовый Да Да(совпадения не допускаются)  
ДатаРожд Дата/Время Да Нет ≥#01.01.1965# And <#01.01.80#
 

      Таблица: СтоимПоНапр

Имя поля Тип данных Обязательное  поле Индексированное поле
КодНапр Счетчик Да Да(совпадения не допускаются)
НаименНапр Текстовый Да
СтоимЗа 1 км Денежный Да Нет
СтавкаЗаРейс Денежный Да Нет
 

    Схема даталогической модели базы данных (схема данных).

    1. Реализация  БД

    6.1.Разработка  средств реализации  ограничений целостности

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

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

  1. Ограничения на атрибуты (тип атрибута, диапазон допустимых значений).

      2.   Число кортежей отношения должно  быть равно числу первичных  ключей  (наличие кортежей –дубликатов  не допускается).

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

      Второе  ограничение накладывается на отношения на этапе заполнения таблиц данными о БД.

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

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

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

  1. Потенциальный ключ отношения не может иметь пустого значения (NULL). Так как объект, не имеющий идентичности, не существует.
  2. Если r2 – некоторое отношение с внешним ключом X , то  должно существовать такое базовое отношение r1 с первичным ключом K , что каждое значение  X в r2 совпадает со значением К в каком-либо  кортеже отношения r1.
 

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

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

    6.2.Разработка процедур ведения БД

    (добавление, удаление, изменение,  контроль)

       

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

      Запрос  на удаление УдалениеВременныхДанных:

      DELETE ИтогиДня.Дата, ИтогиДня.КодРейса, ИтогиДня.ЧислоПроданБил, ИтогиДня.Сумма

      FROM ИтогиДня;

      Запрос  на добавление ПриобретМеста:

      INSERT INTO [Проданные места] ( КодРейса, Дата, Место, Цена )

      SELECT Forms!Билет4!Рейс AS Рейс, Forms!Билет4!Дата AS дата, Forms!Билет4!Место AS место, Forms!Билет4!Цена AS цена;

      Запрос  на добавление Подсчет(Мест/Суммы):

      INSERT INTO ИтогиДня ( КодРейса, Дата, ЧислоПроданБил, Сумма )

      SELECT [Проданные места].КодРейса, [Проданные  места].Дата, Count([Проданные места].Место) AS [Count-Место], Sum([Проданные места].Цена) AS [Sum-Цена]

      FROM [Проданные места]

      GROUP BY [Проданные места].КодРейса, [Проданные места].Дата;

 

    6.3.Разработка процедур реализации запросов и интерфейса пользователя.

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

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

      ВидСамолета. Запрос для получения количества мест в самолете в определенный день и рейс. Связывает отношения РасписаниеРейсов, ОбслуживаниеРейсов, Самолеты.

      SELECT РасписаниеРейсов.КодРейса, ОбслужРейса.Дата,

РасписаниеРейсов.ВрОтпр, Самолеты.КоличМест AS КоличМест,

      Самолеты.ТипСам

      FROM РасписаниеРейсов INNER JOIN (Самолеты INNER JOIN

ОбслужРейса ON Самолеты.НомСам=ОбслужРейса.НомСам) ON

РасписаниеРейсов.КодРейса=ОбслужРейса.КодРейса

      GROUP BY РасписаниеРейсов.КодРейса, ОбслужРейса.Дата,

РасписаниеРейсов.ВрОтпр, Самолеты.ТипСам

      HAVING (((РасписаниеРейсов.КодРейса)=Forms!Билет2!ПолеСоСписком31)

And ((ОбслужРейса.Дата)=Forms!Билет1!Поле16));

      ВрДвижРейса. Запрос, определяющий время отправления и прибытия каждого рейса.

      SELECT РасписаниеРейсов.ВрОтпр AS часы, РасписаниеРейсов.ВрПриб 

AS врдвиж

      FROM РасписаниеРейсов

      WHERE(((РасписаниеРейсов.КодРейса)=[Forms]![Изменение ОбслуживаниеРейса]![КодРейса])); 

      Время отправл. Запрос используется для получения расписания движения самолетов в определенный день и по определенному маршруту (дата и пункт назначения вводятся в форме “Билет1”, при этом получаем, кроме расписания, и количество мест в самолете. Запрос связывает отношения РасписаниеРейсов, Аэропорты, Самолеты.

      SELECT РасписаниеРейсов.КодМарш, РасписаниеРейсов.КодРейса, РасписаниеРейсов.ВрОтпр, Аэропорты.НазвАэропорта, Самолеты.КоличМест, ОбслужРейса.Дата

      FROM (ДниНедели INNER JOIN (Аэропорты INNER JOIN РасписаниеРейсов ON Аэропорты.КодМарш  = РасписаниеРейсов.КодМарш) ON ДниНедели.КодДня = РасписаниеРейсов.ДеньНедели) INNER JOIN (Самолеты INNER JOIN ОбслужРейса ON Самолеты.НомСам = ОбслужРейса.НомСам) ON РасписаниеРейсов.КодРейса = ОбслужРейса.КодРейса

      WHERE

Информация о работе Проектирование базы данных предметной области «Фирма по продаже пластиковых окон».