Базы данных

Введение
1Основные понятия о базах данных
2Модели представления данных
3Этапы создания базы данных
Заключение
Список использованной литературы

Базы данных

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

2 Модели представления данных
При построении БД особое внимание уделяется моделям данных. Данные не являются для пользователя информацией, пока не представлены в определенной структуре – модели данных.
Модель данных - это абстрактное, самодостаточное, логическое определение объектов, операторов и прочих элементов, в совокупности составляющих абстрактную машину доступа к данным, с которой взаимодействует пользователь. Упомянутые объекты позволяют моделировать структуру данных, а операторы — поведение данных. [1, с. 56].
В настоящее время разработано много различных моделей данных. Основные - это иерархическая, сетевая, реляционная и объектно-ориентированная модели.
Иерархическая модель позволяет строить БД с иерархической древовидной структурой. Дерево - это связный неориентированный граф, который не содержит циклов. Обычно при работе с деревом выделяют какую-то конкретную вершину, определяют её как корень дерева и рассматривают особо - в эту вершину не заходит ни одно ребро. В этом случае дерево становится ориентированным. Связи между записями в иерархической модели данных обычно выполнены в виде ссылок.
На иерархической модели данных основано сравнительно ограниченное количество СУБД, в числе которых можно назвать зарубежные системы IMS, PC/Focus, Team-Up и Data Edge, а также отечественные системы Ока, ИНЭС и МИРИС. [5, с. 30].
Сетевая модель позволяет организовывать БД, структура которых представляется графом общего вида. Каждая вершина графа хранит экземпляры сущностей (записи) и сведения о групповых отношениях с сущностями других типов. Каждая запись может хранить произвольное количество значений атрибутов (элементов данных и агрегатов), соответствующих экземпляру сущности. Связи между записями в сетевой модели обычно выполнены в виде указателей.
Системы на основе сетевой модели не получили широкого распространения на практике. Наиболее известными сетевыми СУБД являются следую­щие: IDMS, dbVistalll, СЕТЬ, СЕТОР и КОМПАС. [5, с. 30].
Сложность практического использования иерархических и сетевых СУБД заставляла искать иные способы представления данных. В 1970 г. сотрудником компании IBM Е.Ф.Коддом была предложена реляционная модель. В настоящее время эта модель является фактическим стандартом, на который ориентируются практически все современные коммерческие СУБД.
Реляционная модель БД представляет объекты и взаимосвязи между ними в виде таблиц, а все операции над данными сводятся к операциям над этими таблицами. [4, с. 114].
Основу реляционной модели данных составляют таблицы, которые содержат данные об однотипных объектах. Таблица реляционной базы данных состоит из множества строк и столбцов. Каждая строка таблицы содержит данные об одном объекте и называется записью (строкой, кортежем). Все записи имеют одинаковую структуру — они состоят из полей (столбцов), в которых хранятся атрибуты (свойства) объекта. Каждое поле записи содержит некоторое свойство представляемого объекта. Каждое поле таблицы может содержать данные определенного типа: текстового, числового, логического, дата-временного и др. Все записи имеют одни и те же поля, поэтому каждый столбец таблицы содержит значения одного и того же свойства объектов, представляемых таблицей. Один из атрибутов является ключевым, т.е. идентифицирует запись. Ключ имеет уникальное значение.
В реляционной базе данных очень важным является понятие связи между таблицами. Связь - это логическое отношение между таблицами. Связь между записями двух таблиц основана обычно на совпадении значений атрибутов, по которым эта связь устанавливается. Связи всегда направлены и имеют следующие типы:
связь «один-к-одному» - одному значению первого элемента данных соответствует одно значение второго элемента;
связь «один-ко-многим» - одному значению первого элемента данных соответствует множество значений второго;
связь «много-ко-многим» - множеству значений первого элемента данных соответствует множество значений второго элемента данных. [1, с. 52].
Широкое распространение реляционных БД объясняется в первую очередь простотой представления и формирования БД, универсальностью и удобством обработки данных, которая осуществляется с помощью декларативного языка запросов SQL (Structured Query Language).
Примерами зарубежных реляционных СУБД являются DB2 (IBM), FoxPro и Paradox (Borland), Access (Microsoft), Clarion (Clarion Software), Oracle (Oracle). К отечественным СУБД реляционного типа относятся системы: ПАЛЬ­МА (ИК АН УССР), а также система HyTech (МИФИ).
Сегодня перспективным считается направление объектно-ориентированных моделей данных. При создании объектно-ориентированных СУБД используются разные методы, а именно: встраивание в объектно-ориентированный язык средств для работы с базами данных; создание объектно-ориентированных библиотек функций для работы с СУБД; расширение существующего языка работы с базами данных объектно-ориентированными функциями; создание нового языка и новой объектно-ориентированной модели данных. Недостатками объектно-ориентированной модели являются высокая по­нятийная сложность, неудобство обработки данных и низкая скорость выпол­нения запросов.
Наибольшее распространение получили следующие СУБД: Jasmine (Computer Associates), Versant (Versant Technologies), ODB-Jupiter (научно-производственный центр «Интелтек Плюс»), а также Iris, Orion и Postgres. [5, с. 42].
3 Этапы создания базы данных
Жизненный цикл создания приложения БД представлен Рис. 2. [3, c. 335]. Этапы не являются строго последовательными, а предусматривают в некоторых случаях возврат к предыдущим этапам.
Рис. 2 Жизненный цикл создания приложения БД
Рассмотрим основные действия, выполняемые на каждом этапе жизненного цикла приложения базы данных.
Планирование разработки БД – это подготовительные действия, позволяющие с максимально возможной эффективностью реализовать этапы жизненного цикла приложения базы данных. Важным шагом на этом этапе является четкое определение технического задания для проекта базы данных.
Определение требований к системе - это описание области применения приложения базы данных и основных пользовательских представлений, которые поддерживаются базой данных.
Под сбором и анализом требований к системе понимается процесс сбора и анализа информации о той части организации, работа которой будет поддерживаться с помощью создаваемого приложения базы данных.
Проектирование базы данных - это процесс создания проекта базы данных, предназначенной для поддержки функционирования предприятия и способствующей достижению его целей. Процесс проектирования базы данных состоит из трех основных этапов: концептуальное, логическое и физическое проектирование. Проектирование базы данных — это итерационный процесс, который имеет свое начало, но не имеет конца и состоит из бесконечного ряда уточнений.
Концептуальная модель данных создается на основе информации, записанной в спецификациях требований пользователей. Концептуальное проектирование базы данных не зависит от выбранной СУБД, создаваемых прикладных программ, используемых языков программирования, типа выбранной вычислительной платформы, а также от любых других особенностей физической реализации. На данном этапе для описания структур данных предметной области строятся информационно-логические модели. Существует множество подходов к построению таких моделей: графовые модели, семантические сети, модель "сущность-связь" и т.д. Наиболее популярной из них оказалась модель "сущность-связь". Основными конструктивными элементами инфологических моделей являются сущности, связи между ними и их свойства (атрибуты).
Логическая модель данных уточняет концептуальную модель и учитывает особенности выбранной модели организации данных в целевой СУБД. В процессе разработки логическая модель данных постоянно тестируется и проверяется на соответствие требованиям пользователей. Для проверки правильности логической модели данных используется метод нормализации. Нормализация гарантирует, что отношения, выведенные из существующей модели данных, не будут обладать избыточностью данных, способной вызвать нарушения в процессе обновления данных после их физической реализации.
На этапе физического проектирования рассматриваются основные отношения, организация файлов и индексов, предназначенных для обеспечения эффективного доступа к данным, а также все связанные с этим ограничения целостности и средства защиты. Между логическим и физическим проектированием существует постоянная обратная связь, так как решения, принимаемые на этапе физического проектирования с целью повышения производительности системы, способны повлиять на структуру логической модели данных.
Выбор целевой СУБД должен производиться с учетом информации о таких общих требованиях к системе, как производительность, простота реорганизации, уровень защищенности и ограничения целостности данных. Цель данного этапа заключается в выборе системы, удовлетворяющей как текущим, так и будущим требованиям организации, при оптимальном уровне затрат, включающих расходы на приобретение СУБД, дополнительного аппаратного и программного обеспечения, а также расходы, связанные с переходом к новой системе и необходимостью переобучения персонала.