Автор работы: Пользователь скрыл имя, 26 Февраля 2013 в 20:27, курсовая работа
Задачи выполнения данного курсового проекта:
Создание базы данных (этот этап является самым главным, поскольку база данных – это ключевой объект в моей программе);
Заполнение базы данных (этот этап может быть выполнен как до написания программы, так и в ходе работы уже готового приложения, которое создано специально для работы с этой базой данных);
ВВЕДЕНИЕ 3
ПЕРЕЧЕНЬ УСЛОВНЫХ ОБОЗНАЧЕНИЙ 4
ГЛАВА 1 5
ВИДЫ СУБД 5
1.1 Реляционная СУБД 5
1.2 Иерархические СУБД 9
1.3 Объектно-ориентированные СУБД 12
1.4 Сетевая СУБД 16
1.5 Анализ видов СУБД. Выбор СУБД для проектирования 18
ГЛАВА 2 19
ОБЗОР СУБД РЕЛЯЦИОННОГО ТИПА 19
2.1 FoxPro 19
2.2 Oracle 23
2.3 Access 25
2.4 Анализ рассматриваемой СУБД. Выбор СУБД для проектирования 29
ГЛАВА 3 30
ПРАКТИЧЕСКАЯ ЧАСТЬ 30
3.1 Концептуальное проектирование 30
3.2 Этап логического проектирования 31
3.3 Проектирование запросов 32
3.4 Проектирование формы 33
3.5 Проектирование отчетов 34
3.6 Макросы 35
3.7 Тестирование программного обеспечения 36
ЗАКЛЮЧЕНИЕ 37
СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ 38
ПРИЛОЖЕНИЕ 39
Курсовой проект
(КП) – это самостоятельная
На данном этапе развития компьютерной техники безопасность личной информации имеет огромное значение. Программное обеспечение (ПО) должно решать проблему незащищенности личной информации.
Программа Базы данных «Сотрудники предприятия «Завод столярных изделий ГП Телеханы»» была разработана согласно учебной рабочей программы по дисциплине «Базы данных и система управления базами данных» для учащихся по специальности 2-40 01 01 «Программное обеспечение экономической и деловой информации».
Программа должна
соответствовать следующим
Задачи выполнения данного курсового проекта:
Реляционная модель (от англ. relation — отношение) была разработана в начале 70-х годов Коддом [1,с.13]. Простота и гибкость модели привлекли к ней внимание разработчиков. В 80-х годах она получила широкое распространение, и реляционные СУБД оказались промышленным стандартом.
Модель опирается на систему понятий реляционной алгебры, важнейшие из которых: таблица, строка, столбец, отношение и первичный ключ, а все операции сводятся к манипуляциям с таблицами.
В реляционной модели информация представляется в виде прямоугольных таблиц. Каждая таблица состоит из строк и столбцов и имеет имя, уникальное внутри базы данных.
Таблица отражает объект реального мира — сущность, а каждая ее строка (запись) отражает один конкретный экземпляр объекта — экземпляр сущности. Каждый столбец таблицы имеет уникальное для своей таблицы имя. Столбцы расположены в таблице в соответствии с порядком следования их имен при ее создании. Таблица не может иметь менее одного столбца.
В отличие от столбцов строки не имеют имен, порядок их следования в таблице не определен, а количество логически не ограничено. Так как строки в таблице не упорядочены, невозможно выбрать строку по ее позиции. Хотя в файле у каждой строки имеется номер, он не характеризует строку. Его значение изменяется при удалении строк из таблицы. Логически среди строк не существует «первой» и «последней».
Реляционные системы исключили необходимость сложной навигации, поскольку данные представлены в них не в виде одного файла, а независимыми наборами, и для отбора данных используются операции реляционной алгебры — прикладной теории множеств.
В каждой таблице реляционной модели должен быть столбец или совокупность столбцов, значения которых однозначно идентифицируют каждую строку таблицы. Этот столбец или их совокупность и называется первичным ключом таблицы (рис. – 1.1.1).
Рисунок 1.1.1 – Организация ссылки от одной таблицы к другой
Если таблица удовлетворяет требованию уникальности первичного ключа, она называется отношением. В реляционной модели все таблицы должны быть преобразованы в отношения. Отношения реляционной модели связаны между собой. Связи поддерживаются внешними ключами. Внешний ключ — это столбец (совокупность столбцов), значение которого однозначно характеризует значение первичного ключа другого отношения (таблицы).
Говорят, что отношение, в котором определен внешний ключ, ссылается на соответствующее отношение, в котором та же совокупность столбцов является первичным ключом.
Схема реляционной таблицы (отношения) представляет собой совокупность имен полей, образующих запись таблицы.
Курсивом в схемах таблиц показаны первичные ключи.
Ядром любой базы данных является модель данных. Модель данных — совокупность структур данных и операций их обработки.
По способу установления
связей между данными различают иерарх
Иерархическая модель позволяет строить базы данных с древовидной структурой. В них каждый узел содержит свой тип данных (сущность). На верхнем уровне дерева в этой модели имеется один узел — «корень», на следующем уровне располагаются узлы, связанные с этим корнем, затем узлы, связанные с узлами предыдущего уровня и т. д., причем каждый узел может иметь только одного предка.
Рисунок 1.2.1 – Общий вид иерархическая древовидной структуры модели БД
Поиск данных в иерархической системе всегда начинается с корня. Затем производится спуск с одного уровня на другой пока не будет достигнут искомый уровень. Перемещения по системе от одной записи к другой осуществляются с помощью ссылок.
Основные достоинства иерархической модели — простота описания иерархических структур реального мира и быстрое выполнение запросов, соответствующих структуре данных, однако, они часто содержат избыточные данные. Кроме того, не всегда удобно каждый раз начинать поиск нужных данных с корня, а другого способа перемещения по базе в иерархических структурах нет.
Указанный недостаток снят в сетевой модели, где теоретически возможны связи «всех информационных объектов со всеми».
Использование иерархической и сетевой моделей ускоряет доступ к информации в базе данных. Но поскольку каждый элемент данных должен содержать ссылки на некоторые другие элементы, требуются значительные ресурсы как дисковой, так и основной памяти ЭВМ.
Рисунок 1.2.2 – Общий вид сетевой структуры модели БД
Недостаток основной памяти, конечно, снижает скорость обработки данных. Кроме того, для таких моделей характерна сложность реализации системы управления базами данных (СУБД).
В объектно-ориентированной парадигме модель предметной области — это класс взаимодействующих объектов, каждый из которых представляется набором свойств (статическими характеристиками) и набором методов работы с этим объектом (что и позволяет отразить «поведение» объекта), и обладающих следующими свойствами.
1. Инкапсуляция — объекты наделяются некоторой структурой и обладают определенным набором операций (методов).
Внутренняя структура объекта скрыта от пользователя; манипуляция объектом, изменение его состояния возможны лишь посредством его методов. Таким образом, объекты можно рассматривать как самостоятельные сущности.
2. Наследование — возможность
создавать из объектов новые
объекты, которые унаследуют ст
3. Полиморфизм — различные объекты могут получать одинаковые сообщения, но реагировать на них по-разному, в соответствии с тем, как реализованы у них методы, реагирующие на сообщения.
В объектно-ориентированных базах данных определены следующие свойства, положенные в основу создания объектно-ориентированных баз данных.
1. Сложные объекты строятся из более простых при помощи конструкторов. Простейшими объектами являются такие объекты, как целые числа, символы, и др. Минимальный набор конструкторов, который должна иметь система, — это конструкторы множеств, списков и кортежей.
2. Идентифицируемость объектов. В модели с идентифицируемостью объектов объект существует независимо от его значения. Таким образом, имеется два понятия эквивалентности объектов: два объекта могут быть идентичны (они представляют собой один и тот же объект) или они могут быть равны (имеют одно и тоже значение). Это влечет два следствия: первое — существование совместно используемых (разделяемых) объектов, а второе — изменения объектов.
3. Инкапсуляция. Идея инкапсуляции связана с одной стороны, с потребностью четко различать состояния (время) спецификации и реализации операций, а с другой, для обеспечения модульности, являющейся основой для структурирования сложных приложений, разрабатываемых группой программистов. Интерпретация этого принципа для баз данных состоит в том, что объект инкапсулирует и программу, и данные.
Таким образом, имеется единая модель для данных и операций, причем информация может быть скрыта, т. е. никакие операции, помимо указанных в интерфейсе, не могут выполняться. Инкапсуляция обеспечивает «логическую независимость данных»: можно изменить реализацию типа, не меняя каких-либо программ, использующих этот тип.
4. Типы и классы. В объектно-ориентированной системе тип обобщает общие черты множества объектов с одинаковыми характеристиками. Понятие класса отличается от понятия типа. Его спецификация совпадает со спецификацией типа, но является более динамическим понятием. Классы используются не для проверки правильности программы, а скорее для создания и манипулирования объектами. В большинстве систем классами можно манипулировать во время выполнения, т. е. изменять их и передавать как параметры.
5. Иерархии классов или типов. Наследование обладает двумя положительными достоинствами. Во-первых, оно является мощным средством моделирования, поскольку обеспечивает возможность краткого и точного описания предметной области. Во-вторых, эта возможность помогает факторизовать спецификации и реализации, совместно используемые в приложениях.
6. Перекрытие, перегрузка и позднее связывание. Чтобы исключить переписывание программ при введении нового типа и добавлении нового экземпляра существующего типа, система не должна связывать имена операций с программами во время компиляции. Поэтому имена операций должны разрешаться во время выполнения. Эта отложенная трансляция называется поздним связыванием. Отметим, что хотя позднее связывание затрудняет проверку типов (а в некоторых случаях делает ее невозможной), оно не отменяет ее полностью.
7. Вычислительная полнота. С точки зрения языка программирования это свойство является очевидным: оно просто означает, что любую вычислимую функцию можно выразить с помощью языка манипулирования данными системы баз данных. С точки зрения базы данных это является новшеством, так как SQL, например, не является полным языком.
8. Расширяемость. Система базы данных поставляется с набором предопределенных типов, но этот набор должен быть расширяемым: нужны средства для определения новых типов и должны отсутствовать различия в использовании системных и определенных пользователем типов. Способы поддержания системой системных и пользовательских типов могут значительно различаться, но эти различия должны быть невидимыми для приложения и прикладного программиста.
9. Стабильность. Стабильность (persistence) означает возможность обеспечить сохранность данных после завершения выполнения одного процесса для последующего использования в другом процессе.
10. Управление вторичной памятью. Управление вторичной памятью является классической чертой систем управления базами данных. Эта возможность обычно поддерживается с помощью набора механизмов: управление индексами, кластеризация данных, буферизация данных, выбор метода доступа и оптимизация запросов.
11. Параллелизм. Система должна обеспечивать пользователям возможность одновременно работать с базой данных. Следовательно, система должна поддерживать стандартное понятие атомарности последовательности операций и управляемого совместного доступа.
12. Восстановление. В случае аппаратных или программных сбоев система должна восстанавливаться, т. е. возвращаться к некоторому согласованному состоянию данных.
13. Средства обеспечения незапланированных запросов. Система должна позволять обрабатывать запросы, не предусмотренные при проектировании базы данных.
В сетевой структуре при тех же основных понятиях (уровень, узел, связь) каждый элемент может быть связан с любым другим элементом.
Сетевая модель СУБД во многом подобна иерархической: если в иерархической модели для каждого сегмента записи допускается только один входной сегмент при N выходных, то в сетевой модели для сегментов допускается несколько входных сегментов наряду с возможностью наличия сегментов без входов с точки зрения иерархической структуры.
Информация о работе Анализ видов СУБД. Выбор СУБД для проектирования