Бд описание предметной области с точки зрения прикладной программы

8. Перечислите и охарактеризуйте основные операции реляционной алгебры?

9. Где используются операции реляционной алгебры?

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

Последовательности преобразований модели данных:

— систематизация объектов реального мира;

— создание информационных структур, описывающих систему объектов реального мира;

— создание структуры данных, которая используется для представления информационных структур в базе данных и прикладных программах;

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

Процесс проектирования базы данных включает три этапа:

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

Анализ предметной области целесообразно разбить на три фазы:

1) анализ требований и информационных потребностей;

Декомпозиция предметной области (на примере магазина)

2) выявление информационных объектов и связей между ними;

3) построение модели предметной области и проектирование схемы БД.

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

На этапе анализа концептуальных требований и информационных потребностей необходимо выполнить;

1) анализ требований пользователей к базе данных (концептуальных требований);

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

3) выявление перспективных задач (перспективных приложений);

4) документирование результатов анализа

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

Рассмотрим примерный состав вопросника, требований к базе данных при анализе различных предметных областей.

Пример 1. Пусть предлагается разработать систему вопросов к БД «Сессия студентов колледжа»:

1. Сколько студентов учится в колледже?

2. Сколько отделений в данном колледже?

3. Как распределены студенты по отделениям отделений и курсам?

4. Сколько дисциплин читается на каждом курсе по каждой специальности?

5. Как часто обновляется информация в базе данных?

6. Сколько преподавателей?

7. Сколько иногородних студентов живет в общежитии, на частных квартирах?

8. Какая преемственность существует между читаемыми курсами?

9. Сколько лекционных аудиторий и аудиторий для проведения практических за­нятий, лабораторий?

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

10. Как информация, представленная в п.п. 1-9, используется в настоящее время (расписание занятий, экзаменов, зачетов и т.д.) и как ее собираются использовать?

11. Сколько раз в день, сколько человек и кто пользуются БД?

Пример 1 (продолжение). Выполним анализ требований к БД «Сессия студентов». Вопрос 1. Для каких типов задач (приложений) проектируется БД? Ответ. Для трех типов задач: Задача 1. Информация о студентах.

Задача 2. Инфор­мация о преподавателях. Задача 3. Информация об успеваемости студентов. Задача 4. Информация о предметах.

Вопрос 2. Какими информационными объектами характеризуются эти задачи? Ответ. Задача 1 характеризуется информационным объектом: личные дела студен­тов. Задача 2 характеризуется информационным объектом: личные дела преподава­телей. Задача 3 характеризуется одним информационным объектом — сессия.

Задача 4 характеризуется одним информационным объектом — предметы.

Вопрос 3. Каким текущим запросам должны удовлетворять данные информационные объекты?

Вопрос 4. Каким перспективным запросам должны удовлетворять информационные объекты в БД «Сессия студентов»?

Пример 2. Пусть требуется разработать требования к локальной БД « Аэропорт ».

Вопрос 1. Для каких типов задач (приложений) проектируется БД? Ответ. Для трех типов задач: Задача 1. Информацияоб обслуживающем персонале. Задача 2. Информация о полетных средствах Задача 3. Информация о графике дви­жения самолетов.

Вопрос 2. Какими информационными объектами характеризуются эти задачи? Ответ. Задача 1 характеризуется тремя информационными объектами: летный со­став, диспетчеры, технический персонал. Задача 2 характеризуется двумя информа­ционными объектами: самолет, взлетное поле.

Задача 3 характеризуется одним ин­формационным объектом — рейсы.

Вопрос 3. Каким текущим запросам должны удовлетворять данные информационные объекты? Ответ.

1. ФИО, звание, должность членов экипажа самолета.

2. Списочный состав диспетчеров.

3. Состав смены технического персонала.

4. Тип самолета, который может обслуживать тот или иной пилот.

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

6. Номер личного дела сотрудника аэропорта.

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

8. Готовность самолета с номером № к полету.

9. Количество часов налета самолета с №.

10. Готовность данной взлетной полосы в настоящее время.

11. Длина данной полосы.

12. Номер (номера) рейса до данного пункта назначения.

13. Какие промежуточные посадки совершает рейс №?

14. Время вылета и расчетное время прибытия рейса №.

15. Время и место регистрации рейса №

16. Время посадки на рейс №.

17. До какого времени задерживается рейс №?

18. Какие типы самолетов обслуживают рейс №.?

19. Какой номер самолета обслуживает рейс N°.?

Вопрос 4. Каким перспективным запросам должны удовлетворять информационные объекты в БД «Аэропорт»?

1. С какого года используется самолет с № в аэропорту, тип самолета?

2. Какое количество часов полета у члена экипажа, ФИО?

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

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

При выборе информационных объектов следует ответить на следующие вопросы:

1. На какие классы можно разбить данные, подлежащие хранению в БД?

2. Какое имя можно присвоить каждому классу данных?

3. Какие наиболее интересные характеристики (с точки зрения пользователя) каж­дого класса данных можно выделить?

4. Какие имена можно присвоить выбранным наборам характеристик?

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

1. Какие типы связей между информационными объектами?

2. Какое имя можно присвоить каждому типу связей?

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

4. Имеют ли смысл какие-нибудь комбинации типов связей?

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

При выявлении условий ограничения целостности проектировщик пытается отве­тить на следующие вопросы:

1. Какова область значений для числовых характеристик?

2. Каковы функциональные зависимости между характеристиками одного инфор­мационного объекта?

3. Какой тип отображения соответствует каждому типу связей?

Пример 1 (продолжение). Для БД «Сессия студентов» выберем следующие сущности: институт, факультет, студент, преподаватель, дисциплина, ведомость. Каждую сущность зададим набором атрибутов (ключевые атрибуты подчеркнем): институт (сокращение , название, подчиненность, адрес, телефон, ФИО ректора).

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

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

ведомость (№ п/п, номер зачетной книжки студента, код дисциплины, семестр, фор­ма сдачи, дата сдачи, отметка, преподаватель). Определим связи между сущностями.

Имя связи учится изучает принадлежит

Связи между объектами

студент, факультет студент, дисциплина институт, факультет

работает преподает экзамен

Рассмотрим некоторые ограничения на характеристики объектов:

1. Значение атрибута «телефон» (сущность — институт ) задается целым положи­
тельным шестизначным числом, задавать значение будем по маске __-__-__.

2. Значение атрибута «код факультета» (сущность факультет) лежит в интервале
0-10.

3. Значение атрибута «курс» (сущность — студент) лежит в интервале 1-6 и хранится первая цифра номера группы.

4. Значение атрибута «семестр» (сущность — студент, дисциплина ) лежит в интерва­ле 1-12.

5. Значение атрибута «число часов» (сущность — дисциплина) лежит в интервале 1-300.

6. Одному студенту может быть приписана только одна группа.

7. Один студент может учиться только на одном факультете.

8. Один студент в семестре сдает от 3 до 10 дисциплин.

9. Один студент изучает в семестре от 6 до 12 дисциплин.

10.Одному преподавателю приписывается только одна кафедра.

11.Один студент может пересдавать одну дисциплину не более трех раз.

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

Построение концептуальной модели предметной области

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

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

Одной из распространенных моделей концептуальной схемы является модель «сущность-связь». Остановимся на наиболее известной модели данного типа, назван­ной по фамилии автора, — модели П. Чена, или ER-модели. Основными конструкция­ми данной модели являются сущности и связи.

Сущность принято определять атрибутами — поименованными характеристика­ми. Например: сущность — студент, атрибуты — ФИО, год рождения, адрес, номер группы и т.д.

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

Понравилась статья? Добавь ее в закладку (CTRL+D) и не забудь поделиться с друзьями:

Источник: studopedia.ru

2. Уровни отображения предметной области

Формирование модели предметной области может осуществляться с учетом двух подходов:

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

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

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

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

Источник: studfile.net

Пример описания предметной области

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

Теоретическая часть

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

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

1. Системный анализ и словесное описание информационных объектов предметной области.
2. Проектирование инфологической модели предметной области — частично формализованное описание объектов предметной области в терминах некоторой семантической модели, например, в терминах ER-модели.
3. Даталогичеcкое или логическое проектирование БД, то есть описание БД в терминах принятой даталогической модели данных.
4. Физическое проектирование БД, то есть выбор эффективного размещения БД на внешних носителях для обеспечения наиболее эффективной работы приложения.

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

Рисунок 1 — Этапы проектирования БД

Системный анализ предметной области

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

В общем случае существуют два подхода к выбору состава и структуры предметной области:

• Функциональный подход — он реализует принцип движения «от задач» и применяется тогда, когда заранее известны функции некоторой группы лиц и комплексов задач, для обслуживания информационных потребностей которых создается рассматриваемая БД. В этом случае мы можем четко выделить минимальный необходимый набор объектов предметной области, которые должны быть описаны.
• Предметный подход — когда информационные потребности будущих пользователей БД жестко не фиксируются. Они могут быть многоаспектными и весьма динамичными. Мы не можем точно выделить минимальный набор объектов предметной области, которые необходимо описывать. В описание предметной области в этом случае включаются такие объекты и взаимосвязи, которые наиболее характерны и наиболее существенны для нее. БД, конструируемая при этом, называется предметной, то есть она может быть использована при решении множества разнообразных, заранее не определенных задач. Конструирование предметной БД в некотором смысле кажется гораздо более заманчивым, однако трудность всеобщего охвата предметной области с невозможностью конкретизации потребностей пользователей может привести к избыточно сложной схеме БД, которая для конкретных задач будет неэффективной.

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

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

Пример описания предметной области

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

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

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

В библиотеке ведется картотека читателей.

На каждого читателя в картотеку заносятся следующие сведения:

• фамилия, имя, отчество;
• домашний адрес;
• телефон (будем считать, что у нас два телефона — рабочий и домашний);
• дата рождения.

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

Каждый читатель может одновременно держать на руках не более 5 книг. Читатель не должен одновременно держать более одного экземпляра книги одного названия.

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

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

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

• номер билета читателя, который взял книгу;
• дата выдачи книги;
• дата возврата.

Предусмотреть следующие ограничения на информацию в системе:

1. Книга может не иметь ни одного автора.
2. В библиотеке должны быть записаны читатели не моложе 17 лет.
3. В библиотеке присутствуют книги, изданные начиная с 1960 по текущий год.
4. Каждый читатель может держать на руках не более 5 книг.
5. Каждый читатель при регистрации в библиотеке должен дать телефон для связи: он может быть рабочим или домашним.
6. Каждая область знаний может содержать ссылки на множество книг, но каждая книга может относиться к различным областям знаний.

С данной информационной системой должны работать следующие группы пользователей:

• библиотекари;
• читатели;
• администрация библиотеки.

При работе с системой библиотекарь должен иметь возможность решать следующие задачи:

1. Принимать новые книги и регистрировать их в библиотеке.
2. Относить книги к одной или к нескольким областям знаний.
3. Проводить каталогизацию книг, то есть назначение новых инвентарных номеров вновь принятым книгам, и, помещая их на полки библиотеки, запоминать место размещения каждого экземпляра.
4. Проводить дополнительную каталогизацию, если поступило несколько экземпляров книги, которая уже есть в библиотеке, при этом информация о книге в предметный каталог не вносится, а каждому новому экземпляру присваивается новый инвентарный номер и для него определяется место на полке библиотеки.
5. Проводить списание старых и не пользующихся спросом книг. Списывать можно только книги, ни один экземпляр которых не находится у читателей. Списание проводится по специальному акту списания, который утверждается администрацией библиотеки.
6. Вести учет выданных книг читателям, при этом предполагается два режима работы: выдача книг читателю и прием от него возвращаемых им книг обратно в библиотеку. При выдаче книг фиксируется, когда и какой экземпляр книги был выдан данному читателю и к какому сроку читатель должен вернуть этот экземпляр книги. При выдаче книг наличие свободного экземпляра и его конкретный номер могут определяться по заданному уникальному шифру книги или инвентарный номер может быть известен заранее. Не требуется вести «историю» чтения книг, то есть требуется отражать только текущее состояние библиотеки. При приеме книги, возвращаемой читателем, проверяется соответствие возвращаемого инвентарного номера книги выданному инвентарному номеру, и она ставится на свое старое место на полку библиотеки.
7. Проводить списание утерянных читателем книг по специальному акту списания или замены, подписанному администрацией библиотеки.
8. Проводить закрытие абонемента читателя, то есть уничтожение данных о нем, если читатель хочет выписаться из библиотеки и не является ее должником, то есть за ним не числится ни одной библиотечной книги.

Читатель должен иметь возможность решать следующие задачи:

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

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

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

Варианты индивидуальных заданий для выполнения семантического анализа предметно области:

1. Салон видео проката.

2. Салон аудио проката.

3. Магазин «Продукты».

4. Магазин «Газеты и журналы».

5. Магазин «Парфюмерия».

6. Магазин «Обувь».

7. Магазин «Цветы».

8. Магазин «Спорттовары».

9. Магазин «Бытовая химия».

10. Магазин «Книги».

11. Отдел кадров предприятия.

12. Магазин «Аптека».

14. Магазин «Стройматериалы».

15. Магазин «Сантехника».

16. Магазин «Мороженное».

17. Магазин «Одежда».

18. Интернет — магазин «Электроника».

19. Магазин «Компьютерной техники».

20. Магазин-склад «Мебель».

21. Магазин «Электроинструмент».

22. Магазин «Канцелярские товары».

23. Магазин «Кондитерские изделия».

24. Ремонтная мастерская техники (моб. Телефонов, орг техники, комп. Техники и т.п.)

25. Бухгалтерия предприятия

Популярное:

Модели организации как закрытой, открытой, частично открытой системы: Закрытая система имеет жесткие фиксированные границы, ее действия относительно независимы.

Почему стероиды повышают давление?: Основных причин три.

Почему 1285321 студент выбрали МегаОбучалку.

Система поиска информации

Источник: megaobuchalka.ru