Этапы проектирования (моделирования) Баз данных

Методах проектирования БД.

Предназначена: Для студентов всех форм обучения и специальностей.

План лекции.

Введение. Общие сведения о Базах данных.

Проектирование Базы данных.

1.1. Моделирование данных.

Инфологическая модель Базы данных.

Требования, предъявляемые к инфологической модели (ИнфМ).

2.2. Построение Модели «Сущность–связь»

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

Важнейшая задача компьютерных систем - хранение и обработка данных.

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

Этапы проектирования (моделирования) Баз данных.

Разработка БД выполняется с помощью моделирования данных.

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

Процесс проектирования (моделирования) данных можно условно разделить на несколько этапов – уровней в следующей последовательности, рис. 1:

■ Рассмотрение предметной области.

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

■ Дата-Логическое моделирование.

■ Физическое проектирование.

Рис. 1. Уровни моделей данных.

|■} Предметная область – это «внешний уровень», определяющий требования к данным со стороны пользователей и прикладных программ, рис. 1.

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

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

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

|■}Первая инфологическая модель или «человеко-ориентированная» модель, идущая после предметной области, полностью независима от физических параметров среды данных. Этой средой может быть также память человека, а не ЭВМ. Поэтому, инфологическая модель не должна изменяться до тех пор, пока какие-то изменения в реальном мире не потребуют изменения в ней некоторого определения, чтобы эта модель продолжала отражать предметную область.

Первая инфологическая модель данных, обычно выражается диаграммой «сущность-связь» или ER–диаграммой, (Entity-Relationship) которая представляется одной из стандартных нотаций (образов), принятых для отображения подобных диаграмм.

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

|■} Дата–Логическая модель данных – описывает факты и объекты,

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

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

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

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

Физическим аналогом экземпляра обычно является запись в таблице базы данных. Как и записи в таблице реляционной СУБД, экземпляры сущности должны быть уникальными, то есть полный набор значений их атрибутов не должен дублироваться. И так же, как и поля в таблице, атрибуты могут быть ключевыми и неключевыми. На этапе логического проектирования для каждого атрибута обычно определяется примерный тип данных – строковый, числовой и др. Конкретизация происходит на этапе физического проектирования, так как различные СУБД поддерживают разные типы данных и ограничения на их длину или точность.

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

Логический уровень - это абстрактный взгляд на данные, на нем данные представляются так, как выглядят в реальном мире, и могут называться так, как они называются в реальном мире, например " Постоянный клиент", "Отдел" или "Фамилия сотрудника".

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

|■} Физическая модель данных – связана с организацией внешней памяти,

используемой в данной операционной среде.

Физическая модель данных зависит от конкретной СУБД, фактически являясь

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

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

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

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

В отличие от инфологической модели данных, физическая модель полностью зависит от конкретной СУБД, поэтому в ней должны быть учтены:

■ Ограничения на длину имен объектов базы данных – таблиц, столбцов,

индексов.

■ Использование специальных символов в именах,

■ Допустимые типы данных и их внутреннее представление на

устройствах хранения данных в ЭВМ.

Одной и той же инфологической модели данных могут соответствовать

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

◄ Физическая модель рассматривается как «Внутренний уровень», который связан с физическим размещением данных в памяти ЭВМ. На этом уровне формируется физическая модель БД, содержащая структуры хранения данных в памяти ЭВМ, включая описание форматов данных, порядок их логического или физического упорядочения, размещения по типам устройств, а также характеристики и пути доступа к данным.

От параметров физической модели зависят такие характеристики функционирования БД как:

■ Объем памяти.

■ Время реакции системы.

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

Структура файлов БД определяется на этапах инфологического и логического проектирования, а формирование структуры - на этапе физического проектирования БД.

*** Структура файла – это поименованная совокупность логически

взаимосвязанных атрибутов.

|■} Готовая База данных – является результатом последнего этапа создания БД.

Для её создания и пользуется «Трехуровневая архитектура», рис. 1:

■ Инфологический.

■ Даталогический.

■ Физический.

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

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

1.1. Моделирование данных.

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

*** Цель моделирования данных – состоит в обеспечении разработчика информационной системы (ИС) концептуальной схемой базы данных в форме одной модели или нескольких локальных моделей, которые относительно легко могут быть отображены в любой системе Базы данных. Наиболее распространенным средством моделирования данных являются диаграммы "сущность-связь" (ERD). С помощью ERD осуществляется детализация накопителей данных ER– диаграммы, а также документируются информационные аспекты бизнес-системы, включая идентификацию объектов, важных для предметной области (сущностей), свойств этих объектов (атрибутов) и их связей с другими объектами.

*** Проектирование баз данных — процесс создания схемы базы данных и определения необходимых ограничений целостности.

*** Моделирование данных – это процесс создания логического

представления структуры базы данных.

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

Основные задачи, решаемые при проектировании (моделировании) БД:

■ Обеспечение хранения в БД всей необходимой информации.

■ Обеспечение возможности получения данных по всем необходимым

запросам.

■ Сокращение избыточности и дублирования данных.

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

Дописать схему.

Рис. 7. Этапы проектирования – моделирования БД.

|¨} Лингвистические отношения.

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

|¨} Алгоритмические связи показателей.

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

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

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

Графическое представление является наиболее наглядным и простым для восприятия и анализа, поэтому мы воспользуемся в дальнейшем именно графическим способом отображения модели «объект — свойство — отношение».

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

При отражении в информационной системе каждый объект представляется своим идентификатором, который отличает один объект класса от другого, а каждый класс объектов представляется именем этого класса. Так, для объектов класса «ИЗУЧАЕМЫЕ ПРЕДМЕТЫ» идентификатором каждого объекта будет «НАЗВАНИЕ ПРЕДМЕТА». Идентификатор должен быть уникальным.

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

Каждому классу объектов в инфологической модели присваивается уникальное имя. Именем класса объектов является грамматический оборот существительного (существительное, у которого могут быть прилагательные и предлоги). Если имя состоит из нескольких слов, то желательно, чтобы первым стояло существительное. Существительное должно употребляться в единствен ном, а не во множественном числе. Поэтому для рассмотренного выше класса объектов «ИЗУЧАЕМЫЕ ДИСЦИПЛИНЫ» лучше дать имя «ДИСЦИПЛИНА ИЗУЧАЕМАЯ». Если в предметной области традиционно используются разные имена для обозначения какого-либо класса объектов (т. е. имеет место синонимия), то все они должны быть зафиксированы при описании системы, затем одно из них выбирается за основное, и только оно должно в дальнейшем использоваться в ИЛМ. Помимо имени класса объектов в ИЛМ может использоваться его короткое кодовое обозначение.

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

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

Агрегированные объекты соответствуют обычно какому-либо процессу, в который оказываются «вовлеченными» другие объекты. Например, агрегированный объект «ПОСТАВКА» объединяет в себе объекты «ПОСТАВЩИК», который поставляет продукцию, «ПОТРЕБИТЕЛЬ», который получает эту продукцию, а также саму поставляемую «ПРОДУКЦИЮ». Своеобразным объектом является «ДАТА ПОСТАВКИ». Агрегированный объект может, так же как и простой объект, иметь характеризующие его свойства. В рассматриваемом примере таким свойством может быть размер поставки.

Агрегированные объекты обычно называются отглагольными существительными (например, поставлять — поставка, выпускать — выпуск, продавать — продажа и т. д.).

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

необходимо связать с условными обозначениями тех объектов, которые образуют этот агрегированный объект. Свойства агрегированного объекта изображаются так же, как и для простого объекта. На рис. 2.16 изображен агрегированный объект «ПОСТАВКА ПРОДУКЦИИ».

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

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

Ограничения могут быть внутренними (неявными) и явными.

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

-------------------------------------------------------

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

а) Унарная связь

б) Бинарная связь

в) Тернарная связь.

Рис.1.5. Примеры связей различной степени

Различают тип связи и экземпляр связи. Тип связи определяется её име-нем, обязательностью, степенью и кардинальностью, например, бинарная связь учится между сущностями ГРУППА и СТУДЕНТ, обязательная для студента, кардинальностью 1:n. А экземпляр связи – это конкретная связь между студентом Сидоровым и группой Н-11, в которой он учится.

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

Множества экземпляров сущностей, значения атрибутов сущностей и экземпляры связей между ними могут изменяться во времени. Поэтому каждому моменту времени можно сопоставить некоторое состояние предметной области. Состояния ПО должны подчиняться совокупности правил, которые характеризуют семантику предметной области. В базе данных эти правила могут быть заданы с помощью так называемых ограничений целостности, которые накладываются на атрибуты сущностей, типы сущностей, типы связей и/или их экземпляры. Фактически, ограничения целостности – это правила, которым должны удовлетворять значения данных в БД. Например, для библиотеки можно привести такие ограничения целостности: количество экземпляров книги не может быть отрицательным; номер паспорта читателя должен быть уникальным; каждая книга относится к определённому разделу рубрикатора ББК – библиотечно-библиографической классификации и т.д.

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

• вручную, если изменения в данные вносит пользователь (например, запись сведений о выдаче абоненту книги в библиотеке);
• автоматизировано, если изменения инициируются пользователем, но вы-полняются программно (например, обновление списка должников в библиотеке – читателей, которые просрочили дату возврата книг);
• автоматически, если данные поступают в электронном виде и обрабатыва-ются программой без участия человека (это касается, например, автоматизированных систем управления производством).

Правильность обновлений может контролироваться программно, но правильнее контролировать их автоматически с помощью ограничений целостности БД.

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