Информационное обеспечение(лекции)

Определение требований в системе

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

Рисунок 2.1 - Жизненный цикл информационной системы

41

Сбор и анализ требований пользователей

На этом этапе производится сбор и анализ требований пользователей из всех возможных областей применения БД.

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

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

Выбор целевой СУБД

Выполняется подбор наиболее подходящей СУБД для приложения базы данных.

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

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

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

Реализация

Создание внешнего, концептуального и внутреннего определений базы данных и прикладных программ.

Конвертирование и загрузка данных (первичное наполнение)

Преобразование и загрузка данных (и прикладных программ) из старой системы в новую.

Тестирование

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

Эксплуатация и сопровождение

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

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

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

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

2.2.1Цели и подходы к проектированию баз данных

Процесс проектирования БД представляет собой сложный процесс проектирования отображения:

«Описание предметной области» «схема внутренней модели базы данных».

42

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

–информационный,

–внешний,

–концептуальный,

–внутренний.

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

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

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

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

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

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

43

Такие БД объединяют данные, относящиеся к какой-либо предметной области (например, финансам, обучению, торговле и т.п.) и называются предметными БД (соотносящимся с предметами организации, а не с ее информационными приложениями).

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

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

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

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

иустранение возможности возникновения противоречий из-за хранения в разных местах сведений об одном и том же объекте. Так называемый, «чистый» проект БД – « Каждый факт в одном месте».

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

1.Каким образом отобразить объекты предметной области в абстрактные объекты модели данных, чтобы это отображение не противоречило семантике предметной области и было по возможности лучшим (эффективным, удобным

ит.д.)? Часто эту проблему называют проблемой логического проектирования баз данных.

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

44

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

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

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

различают: концептуальную инфологическую модель и концептуальную даталогическую модель, внешнюю инфологическую модель и внешнюю даталогическую модель.

Рисунок 2.2 - Этапы проектирования базы данных

45

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

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

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

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

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

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

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

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

46

2.3 Инфологическое проектирование базы данных

Все этапы проектирования БД подразумевают создание моделей данных об интересующей предметной области. Моделирование данных упрощает понимание смысла элементов данных, способствует более плодотворному общению пользователей и разработчиков.

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

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

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

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

Таблица 2.1 – Критерии эффективности моделей данных

47

2.3.1 Модель «сущность-связь»

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

–семантические сети;

–язык инфологического моделирования;

–ЕR-диаграммы.

Наибольшую популярность из-за доступности, наглядности и компактности приобрел подход моделирования «сущность-связь».

Модель «сущность-связь» (Entity-Relationship model) разработана Ченом в 1976 году с целью упрощения концептуального проектирования баз данных.

Основными элементами этой модели являются:

–сущности;

–атрибуты;

–связи.

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

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

На ER-диаграммах сущность представляется прямоугольником с именем сущности внутри.

Атрибут – неотъемлемое свойство сущности или связи. Именно по значениям атрибутов можно идентифицировать экземпляр сущности. Значения атрибутов представляют основную часть сведений, хранящихся в БД.

На ER-диаграммах атрибут представляется овалом (эллипсом), соединенным с соответствующей сущностью линией и с именем атрибута внутри.

С понятием атрибута тесно связано понятие домена.

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

Атрибуты делятся на:

–простые;

–составные;

–однозначные;

–многозначные;

–производные.

Простой атрибут состоит из одного компонента с независимым существованием.

48

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

Однозначный атрибут содержит одно значение для одного экземпляра сущности.

Многозначный атрибут может содержать несколько значений для одного экземпляра сущности.

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

Вопрос однозначной идентификации экземпляров сущности связан с понятием ключа.

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

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

На ER-диаграммах имена атрибутов, выбранных в качестве первичного ключа, подчеркиваются.

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

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

Пример ER-диаграммы с обозначениями сущностей, их атрибутов и связей представлен на рисунке 2.3.

Рисунок 2.3 - Пример ER-диаграммы

49

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

Если связь определена между двумя сущностями, то ее степень - 2, а называется такая связь бинарной. Связь между тремя сущностями называется тернарной, четырьмя сущностями – кватернарной и т.д. В общем случае связь между п сущностями называется n - арной. Примеры различных связей представлены на рисунке 2.4.

Рекурсивная связь – связь, в которой одни и те же сущности участвуют несколько раз в разных ролях.

Рекурсивная связь часто называют унарной. Пример такой связи представлен на рисунке 2.4, г. В приведенном примере каждый студент из сущности СТУДЕНТ может исполнять обязанности дежурного по отношению к другим студентам той же сущности.

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

С этими ограничениями связано понятие показателя кардинальности связи.

Показатель кардинальности указывает количественное соотношение экземпляров сущностей для каждой связи.

Классическими признаны бинарные связи с показателями кардинальности «ОДИН-К-ОДНОМУ», «ОДИН-КО-МНОГИМ», «МНОГИЕ- КО-МНОГИМ».

Пусть в предметной области выделены сущности А и В.

1.Связь ОДИН-К-ОДНОМУ (1:1): в каждый момент времени каждому экземпляру сущности А соответствует не более одного экземпляра сущности В (рисунок 2.5).

Декан осуществляет свою деятельность на одном факультете вуза.

2.Связь ОДИН-КО-МНОГИМ (1:М): каждому экземпляру сущности А соответствуют О, 1 или несколько представителей сущности В (рисунок 2.6).

В квартире может проживать несколько жильцов.

3.Связь МНОГИЕ-КО-МНОГИМ (М:М): каждому экземпляру сущности А соответствуют 0, 1 или несколько представителей сущности В, каждому экземпляру сущности В соответствуют 0, 1 или несколько представителей сущности А (рисунок 2.7).

Процесс обучения осуществляется множеством преподавателей с множеством студентов.

50