Лекции по Базам данных. лекции. Развитие технологий обработки данных

• Название: Развитие технологий обработки данных
• Анкор: Лекции по Базам данных
• Дата: 16.02.2023
• Размер: 0.53 Mb.
• Имя файла: лекции.docx
• Тип: Документы; #940385
• страница: 13 из 22

Физическое проектирование базы данных.

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

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

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

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

3. Разработка средств защиты создаваемой системы.

Разработка приложений.

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

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

Проектирование транзакций.

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

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

Проектирование транзакций заключается в следующем:

1. Определяются данные, которые могут использоваться транзакцией.

2. Определяются функциональные характеристики транзакции.

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

4. Определяется степень важности и интенсивность использования каждой транзакции.

Рассмотрим три основных типа транзакций: извлечения; обновления; смешанные транзакции.

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

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

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

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

Проектирование пользовательского интерфейса.

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

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

1. Содержательное название.

2. Ясные и понятные инструкции.

3. Логически обоснованные группировки и последовательности полей.

4. Визуально привлекательный вид окна формы или поля отчета.

5. Легко узнаваемые названия полей.

6. Согласованную терминологию и сокращения.

7. Согласованное использование цветов.

8. Визуальное выделение пространства и границ полей ввода данных.

9. Удобные средства перемещения курсора.

10. Средства исправления отдельных ошибочных символов и целых полей.

11. Средства вывода сообщений об ошибках при вводе недопустимых значений.

12. Особое выделение необязательных для ввода полей.

13. Средства вывода пояснительных сообщений с описанием полей.

14. Средства вывода сообщения об окончании заполнения формы.

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

Основными шагами при проектировании баз данных являются:

Шаг 1. Необходимо определить список данных, которые нужно хранить в данной базе данных.

Шаг 2. Нужно определить состав и структуру таблиц входящих в базу данных.

Шаг 3. Предполагается назначить ключевые поля для каждой из таблиц базы данных.

Шаг 4. Необходимо выполнить нормализацию таблиц входящих в базу данных.

Шаг 5. Нужно предопределить и установить связи между этими таблицами.

Рассмотрим каждый из приведенных шагов на примере проектирования базы данных информационной системы.

Шаг 1. Определяем список данных, которые необходимо хранить в базе данных.

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

Шаг 2. Определяем состав и структуру таблиц.

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

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

Определение структуры таблицы.

Что означает создать или спроектировать структуру таблицы? Это означает или включает следующие этапы: определение числа полей таблицы; присвоение каждому полю своего имени; определение типа поля; назначение числа позиций для размещения информации в каждом поле или ширине столбца; присвоение таблице уникального имени.

Как определяется число полей? Оно определяется в каждой задачи на основе анализа предметной области. Анализ производится путем выбора из исходной информацию, связанную по смыслу с информационным объектом. Каждое поле должно иметь уникальное имя. Имена полям базы данных должны присваиваться таким образом, чтобы они отражали содержимое этих полей и при этом легче запоминались. Это облечет дальнейшею работу по проектированию и эксплуатации.

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

Приведем наиболее часто используемые поля.

1. Текстовое поле. Размер в этом случае является основным свойством текстового поля.

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

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

4. Логическое поле. Данный тип поля является специальным типом и предназначен для ввода логических данных. Логическое поле имеет только два значения (Да или Нет; 0 или 1; Истина или Ложь и т.п.). Для того, чтобы выразить любой из приведенных логических значений, достаточно 1 Байта. Это удобное свойство логического поля.

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

6. Поле объекта ОLЕ. Такое поле предназначено для таких объектов, как картинки, музыкальные клипы и видеозаписи. Приведенные объекты специфичны по размеру и форме и поэтому требуют специального формата поля.

7. Поле типа МЕMО. Наличие данного поля обусловлено недостатком текстового поля, связанного с ограничением его размера. Текстовое поле ограничено размером, то есть, в текстовое поле вводится информация, которая не может превышать 256 символов. Если встанет необходимость в хранении текста большей длины нужно воспользоваться полем типа MЕМО, в котором может храниться до 65 535 символов. Сущность этого поля схожа с нашим понятием о гиперссылке. То есть реально данные введенные в это поле не хранятся в данном поле а расположены на диске или на сервере, а в поле хранится указатель того места, где расположен текст.

8. Поле Счетчик. Это поле используется, когда нам нужно автоматическое наращивание, как свойство поля. При вводе каждая запись в данное поле одновременно вводится число, которое автоматически увеличивается на единицу в сравнении со значение того же поля в предыдущей записи.

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

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

Шаг 3. Назначаем ключевые поля для каждой таблицы.

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

Уникальное поле можно создать искусственно, если ни одно поле таблицы не приемлемо именно в таком качестве.

Шаг 4. Выполняем нормализацию таблиц.

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

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

Шаг 5. Установление связей между таблицами.

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

Приведем преимущества хранения данных в связанных таблицах:

      отсутствие дублирования приводит к экономии времени;

      значительное уменьшение размера базы данных, которое соответственно экономит дисковое пространство на компьютере и облегчает перенос базы данных в случае необходимости;

      количество ошибок существенно сокращается.

Основные этапы проектирования базы данных

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

Даталогическая модель базы данных (ДЛМ).

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

Физическая модель базы данных.

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

Внешняя модель.

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

Инфологическая модель предметной области.

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

Взаимосвязь этапов проектирования базы данных.

Предварительная инфологическая модель строится еще на предпроектной стадии, что дает нам право утверждать что инфологическая модель предметной области является первой. Только после построения инфологической модели на предпроектной стадии уже строится даталогическая модель. Затем в любой последовательности строятся физическая и внешняя модели, а могут и одновременно (Рис. 5.1). При проектировании базы данных необходимо предусмотреть возможность возврата на предыдущие уровни. Имеется возможность возврата на предыдущие уровни двумя способами. Первый предопределяет необходимость пересмотра результата проектирования. А второй определен необходимостью уточнить предыдущую модель с целью получения дополнительной информации для проектирования или при вскрытия противоречий в модели. Уточняется обычно инфологическая модель.

Инфологическое моделирование.

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

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



Рисунок 5.1 – Этапы проектирование базы данных и их взаимосвязь

Основными требованиями к инфологической модели являются:

      адекватное отображение предметной области;

      непротиворечивость;

      отсутствие неоднозначности трактовки;

      возможность легкой расширяемости, обеспечивающая ввод данных без изменения ранее определенных;

      обеспечение возможности композиции и декомпозиции модели.

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