Основные этапы проектирования моделей данных

 

Содержание

 

Введение

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

База данных – это  совокупность самостоятельных материалов (статей, расчётов, нормативных актов, судебных решений и иных подобных материалов), систематизированных таким образом, чтобы эти материалы могли быть найдены и обработаны с помощью электронной вычислительной машины (ЭВМ).

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

Цель -  изучить основные этапы проектирования моделей данных.

Задачи:

1. Дать определение базы данных;
2. Рассмотреть различные представления о данных в базах данных;
3. Описать модели данных (внешнее представление, концептуальная модель, структура хранения);
4. Изучить этапы проектирования базы данных;
5. Жизненный цикл проектирования базы данных;
6. Сравнить жизненные циклы БД.

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

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

 

    Среди множества СУБД  наиболее часто используются  пакеты программ dBASE разных версий, FoxBase +, FoxPro, Fox Soft Ware, Clipper, совместимые с dBASE по системе команд и файлам.

 

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

 

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

 

 

Глава 1. Различные представления о данных в базах данных

База данных (БД) - поименованная совокупность структурированных данных, относящихся к определенной предметной области.

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

Система управления базами данных (СУБД) - комплекс программных и языковых средств, необходимых для создания и модификации базы данных, добавления, модификации, удаления, поиска и отбора информации, представления информации на экране и в печатном виде, разграничения прав доступа к информации, выполнения других операций с базой [2].

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

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

 
Рис. 1 «Обобщение представления пользователей о данных»

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

Следующий этап разработки базы данных предполагает выбор представления концептуальной модели с помощью модели данных конкретной СУБД. Полученное таким образом представление концептуальной модели называется логической моделью БД. Или другими словами, логическая модель – это концептуальная схема, специфицированная в языке конкретной СУБД. Логическая модель представляет данные и элементы данных вне зависимости от их содержания и среды хранения. Далее разработчик системы средствами СУБД отображает полученную логическую модель БД в память ЭВМ и определяет методы доступа. Полученное представление данных в памяти ЭВМ называется внутренним представлением или структурой хранения. Прикладные программы работают с логической моделью, причем каждому пользователю представляется подмножество этой логической модели (подсхема), отражающее его представление о предметной области. Каждая прикладная программа "видит" и обрабатывает только те данные, которые необходимы именно ей.

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

 
Рис. 2 «Различные представления о данных в БД»

На данной схеме выделены три различных уровня описания данных (внешний, концептуальный, внутренний). Эти уровни формируют так называемую трехуровневую архитектуру ANSI/SPARC, предложенную в 1975 году Комитетом планирования стандартов и норм SPARC (Standards Planning and Requirements Committee) Национального института стандартизации США (American National Standards Institute – ANSI). Основная цель этой архитектуры состоит в отделении пользовательского представления о данных в базе данных от их физического представления. Использование таких представлений о данных позволяет обеспечить выполнение основного требования к БД – независимости программ и данных. При изменении прикладных программ может измениться соответствующее внешнее представление, но логическая модель данных не изменяется и, соответственно, не будут изменяться другие прикладные программы. При изменении внутреннего представления (структур хранения) логическая модель не изменяется, соответственно, не изменяются прикладные программы [5].

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

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

• внешнее представление – представление специалиста предметной области (пользователя);

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

• логическая модель и внутреннее представление – представление системного программиста, администрирующего базу данных [4].

 

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

Проектирование данных (базы данных) представляет собой процесс последовательного отображения исследуемых явлений реального мира в виде данных в памяти ЭВМ (рис. 3).

 
Рис. 3 «Общая схема проектирования»

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

Этапы проектирования базы данных:

1. Определить цель создания базы данных, основные ее функции и информацию, которую она должна содержать. База данных должна отвечать требованиям тех, кто будет непосредственно с ней работать. Для этого нужно определить темы, которые должна покрывать база данных, отчеты, которые она должна выдавать, проанализировать формы, которые в настоящий момент используются для записи данных, сравнить создаваемую базу данных с хорошо спроектированной, подобной ей базой.
2. Разработать на бумаге структуру таблиц, которые должна содержать база данных. При проектировании таблиц, рекомендуется руководствоваться следующими основными принципами: информация в таблице не должна дублироваться. Не должно быть повторений и между таблицами.
3. Каждая таблица должна содержать информацию только на одну тему. Сведения на каждую тему обрабатываются намного легче, если содержаться они в независимых друг от друга таблицах. Например, адреса и заказы клиентов хранятся в разных таблицах, с тем, чтобы при удалении заказа информация о клиенте осталась в базе данных.
4. Определить необходимые в таблице поля. Каждая таблица содержит информацию на отдельную тему, а каждое поле в таблице содержит отдельные сведения по теме таблицы. Например, в таблице с данными о клиенте могут содержаться поля с названием компании, адресом, городом, страной и номером телефона. При разработке полей для каждой таблицы необходимо помнить: каждое поле должно быть связано с темой таблицы.
5. Не рекомендуется включать в таблицу данные, которые являются результатом выражения. В таблице должна присутствовать вся необходимая информация. Информацию следует разбивать на наименьшие логические единицы (Например, поля "Имя" и "Фамилия", а не общее поле "Имя").
6. Задать ключевое поле. Для связаи данных из разных таблиц, например, данные о клиенте и его заказы, каждая таблица должна содержать поле или набор полей, которые будут задавать индивидуальное значение каждой записи в таблице. Такое поле или набор полей называют основным ключом.
7. Определить связи между таблицами. После распределения данных по таблицам и определения ключевых полей необходимо выбрать схему для связи данных в разных таблицах. Для этого нужно определить связи между таблицами.
8. Еще раз просмотреть структуру базы данных и выявить возможные недочеты. Желательно это сделать на данном этапе, пока таблицы не заполнены данными.
9. Добавить данные и создайте другие объекты базы данных. Если структуры таблиц отвечают поставленным требованиям, то можно вводить все данные. Затем можно создавать любые запросы, формы, отчеты, макросы и модули.
10. Например в Microsoft Access поддерживаются два способа создания базы данных. Имеется возможность создать пустую базу данных, а затем добавить в нее таблицы, формы, отчеты и другие объекты. Такой способ является наиболее гибким, но требует отдельного определения каждого элемента базы данных. Имеется также возможность сразу создать с помощью мастера базу данных определенного типа со всеми необходимыми таблицами, формами и отчетами. Это простейший способ начального создания базы данных. В обоих случаях останется возможность в любое время изменить и расширить созданную базу данных.
11. Есть две стратегии разработки баз данных: сверху вниз и снизу вверх. Разработка сверху вниз идет от общего к частному. Она начинается с изучения стратегических целей организации, способов, при помощи которых эти цели могут быть достигнуты. Отталкиваясь от этой общей модели, разработчики двигаются «вниз», к все более подробным описаниям и моделям [2].

Рассмотрим проектирование (моделирование) базы данных  на рис. 4.

Краткие комментарии к соответствующим блокам:

В блоках 1,2 необходимо особое внимание обратить на слово "абстрагирование". Имеется ввиду, что проектирование базы данных нужно вести не под конкретный документ, обрабатываемый пользователем, и не под конкретные действия пользователя с этим документом, а под обобщенный (абстрактный) образ документов и обобщенные (абстрактные) действия пользователей.

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

 
Рис.4 «Этапы проектирования базы данных»

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

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

Заметим, что очень важно при проектировании базы данных делать оценки ее возможной работоспособности. Так, по завершении проектирования обобщенного концептуального представления нужно попытаться оценить необходимое число производимых операций с элементами моделей при реализации возможных запросов пользователей. При невозможности в рамках построенной модели ответить на какой-то запрос пользователя или при значительном числе производимых при этом операций (что приведет к невозможности реализации соответствующего запроса в реальном масштабе времени) необходим возврат по схеме (рис. 4) на шаг назад (построение более эффективного обобщенного концептуального представления). Аналогичные оценки необходимо делать и при завершении других этапов проектирования (блоки 5, 7). При этом возможен возврат назад на один или несколько шагов. Так, например, при проектировании логической модели (блок 5) не удается достичь адекватного представления концептуальной модели средствами модели данных СУБД. В этом случае необходимо либо вернуться на шаг назад и выбрать другую СУБД, либо вернуться к блоку 3 и изменить вид концептуальной модели. Так же, если полученные при реализации блока 7 оценки эксплуатационных характеристик не отвечают требованиям пользователя, возможны пересмотры всех ранее полученных решений (блоки 7, 6, 5, 4, 3). Кроме этого, необходим возврат на проектирование обобщенного концептуального представления при изменении внешних требований пользователей, а также при выявленных ошибках проектирования [5].