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

Оглавление

Введение

1. Теоретические аспекты проектирования БД

1.1 Этапы проектирования БД

1.2 Описание модели данных

1.3 Основные проблемы проектирования реляционных БД

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

2.1 Определение сущностей

2.2 Описание атрибутов

2.3 Установление связей между типами сущностей

2.4 Концепция функциональной зависимости

2.5 Нормализация БД

2.6 Построение инфологической модели ПО

3 Выбор СУБД

4 Даталогическое проектирование

4.1 Спецификация файлов БД

4.2 Разработка даталогической модели данных

4.3 Описание средств обеспечения целостности данных

5 Разработка средств обеспечения безопасности данных

6 Реализация запросов на SQL

7 Описание программного средства

7.1 Требования к аппаратному и программному обеспечению

7.2 Функциональное назначение программы

7.3 Входные данные

7.4 Выходные данные

7.5 Руководство пользователя

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

Приложение 1

Приложение 2

Приложение 3

Приложение 4

Введение

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

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

Целью этой работы является создать базу данных в СУБД ACCESS, которая должна будет автоматизировать работу служащих аэропорта.

1. Теоретические аспекты проектирования БД

1.1 Этапы проектирования БД

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

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

· представление предметной области в том виде, как она реально существует;

· как ее воспринимает человек (имеется в виду проектировщик базы данных);

· как она может быть описана с помощью символов.

Говорят, что мы имеем дело с реальностью, описанием (представлением) реальности и с данными, которые отражают это представление.

Данные, используемые для описания предметной области, представляются в виде трехуровневой схемы (так называемая модель ANSI/SPARC):

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

Рисунок 1 - Трехуровневая схема

Отсюда вытекают основные этапы, на которые разбивается процесс проектирования базы данных информационной системы:

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

- обследовали предметную область, изучив ее информационную структуру;

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

- смоделировали и интегрировали все представления.

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

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

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

1.2 Описание модели данных

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

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

Рисунок 2 - Фрагмент иерархической структуры данных

Из структуры понятно, что на одной кафедре может работать несколько преподавателей. Такая связь называется "один ко многим" (одна кафедра - много преподавателей). Но если мы попытаемся добавить в эту структуру группы студентов, то нам понадобится связь "многие ко многим": (один преподаватель может работать со многими группами, а одна группа может учиться у многих преподавателей), а такой связи в иерархической структуре быть не может (т.к. связь может быть только с одним узлом на более высоком уровне). Это основной недостаток подобной структуры базы данных.

Рисунок 3 - Связь многие - ко - многим

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Недостатки: из нижних уровней иерархии нельзя направить информационный поиск по вышележащим узлам.

В сетевой модели данных понятия главного и подчиненных объектов несколько расширены. Любой объект может быть и главным и подчиненным (в сетевой модели главный объект обозначается термином «владелец набора», а подчиненный - термином «член набора»). Один и тот же объект может одновременно выступать и в роли владельца, и в роли члена набора. Это означает, что каждый объект может участвовать в любом числе взаимосвязей.

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

1.3 Основные проблемы проектирования реляционных БД

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

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

модель база данный аэропорт

2. Инфологическое проектирование ПО

2.1 Определение сущностей

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

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

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

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

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

Вабор сущностей (entity set) - множество сущностей одного типа(обладающих одинаковыми свойствами).

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

Спецификация сущностей представлена в таблице 1. В первом столбце таблицы указано наименование сущности. Во втором столбце описательные атрибуты.

Таблица 1

Спецификация сущностей

2.2 Описание атрибутов

Атрибут представляет собой свойство сущности. Это понятие аналогично понятию атрибута в отношении.

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

Спецификация атрибутов сущностей представлена в таблице 2. В первом столбце таблицы указано название сущности. Во втором - наименование атрибута. В третьем столбце указывается тип атрибута.

Таблица 2

Спецификация атрибутов

2.3 Установление связей между типами сущностей

Спецификация связей между сущностями представлена в таблице 3. В первом столбце указан тип связи, где буква M означает «многие». Во втором столбце указано название первой сущности связи, в третьем - название второй сущности связи.

Таблица 3

Спецификация связей

2.4 Нормализация БД

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

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

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

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

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

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

· Первая нормальная форма:

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

Все отношение БД Гостиницы наводится в первой нормальной форме.

· Вторая нормальная форма: