Основные этапы разработки БД и приложения

Пользователи БД и СУБД

Пользователей) можно разделить на три основные категории: конечные пользователи, разработчики и администраторы баз данных.

Классификация баз данных

Архитектура БД

Классификация СУБД

 

Основные функции СУБД

Организация данных. Создание объектов БД.

Управление размещением данных во ВП и в ОП.

Обеспечение целостности данных. Обеспечение безопасности данных.

Обеспечение восстановления БД.

Обработка данных.

Реализация бизнес-логики приложения

Основные этапы разработки БД и приложения

Этап 1. Постановка задач

На первом этапе составляется список всех основных задач, которые должны решаться приложением.

Этап 2. Анализ данных

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

Этап 3 Определение структуры данных.

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

Этап 4. Физическая реализация БД средствами выбранной СУБД.

Этап 5. Создание приложения, включая пользовательский интерфейс.

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

Этап 6. Тестирование, усовершенствование и внедрение приложения.

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

 

Модели организации баз данных

Пример

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

Поэтому, для информационной системы управления персоналом необходимо создать групповое отношение, состоящее из родительской записи ОТДЕЛ (НАИМЕНОВАНИЕ_ОТДЕЛА, ЧИСЛО_РАБОТНИКОВ) и дочерней записи СОТРУДНИК (ФАМИЛИЯ, ДОЛЖНОСТЬ, ОКЛАД). Это отношение показано на (Для простоты полагается, что имеются только две дочерние записи).

Для автоматизации учета контрактов с заказчиками необходимо создание еще одной иерархической структуры: заказчик - контракты с ним - сотрудники, задействованные в работе над контрактом. Это дерево будет включать записи ЗАКАЗЧИК (НАИМЕНОВАНИЕ_ЗАКАЗЧИКА, АДРЕС), КОНТРАКТ(НОМЕР, ДАТА,СУММА), ИСПОЛНИТЕЛЬ (ФАМИЛИЯ, ДОЛЖНОСТЬ, НАИМЕНОВАНИЕ_ОТДЕЛА).

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

 

 

Операции над данными, определенные в иерархической модели:

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

· Изменить значение данных предварительно извлеченной записи. Ключевые данные не должны подвергаться изменениям.

· Удалить некоторую запись и все подчиненные ей записи.

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

· Извлечь следующую запись (следующая запись извлекается в порядке левостороннего обхода дерева).

 

Сетевая модель базы данных

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

 

 

Объектно-реляционные СУБД

Разница между объектно-реляционными и объектными СУБД: первые являют собой надстройку над реляционной схемой, вторые же изначально объектно-ориентированы. Главная особенность и отличие объектно-реляционных (как и объектных) СУБД от реляционных заключается в том, что ОР СУБД интегрированы с Объектно-Ориентированным (OO) языком программирования, внутренним или внешним как C++, Java.

Объектно-реляционными СУБД являются, например, широко известные Oracle Database, Microsoft SQL Server, PostgreSQL, Microsoft Access.

 

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

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

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

 

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

· таблица должна содержать данные об одном типе объектов;

· каждая таблица должна содержать одно поле или несколько полей, образующих уникальный идентификатор (или первичный ключ) для каждой строки;

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

 

Третья нормальная форма

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

 

Простые и составные ключи

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

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

Такой первичный ключ называют составным ключом

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

 

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

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

 

Пользователи БД и СУБД

Пользователей) можно разделить на три основные категории: конечные пользователи, разработчики и администраторы баз данных.

Классификация баз данных

Архитектура БД

Классификация СУБД

 

Основные функции СУБД

Организация данных. Создание объектов БД.

Управление размещением данных во ВП и в ОП.

Обеспечение целостности данных. Обеспечение безопасности данных.

Обеспечение восстановления БД.

Обработка данных.

Реализация бизнес-логики приложения

Основные этапы разработки БД и приложения

Этап 1. Постановка задач

На первом этапе составляется список всех основных задач, которые должны решаться приложением.

Этап 2. Анализ данных

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