Добавил:
Меня зовут Катунин Виктор, на данный момент являюсь абитуриентом в СГЭУ, пытаюсь рассортировать все файлы СГЭУ, преобразовать, улучшить и добавить что-то от себя Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Лекции / Лекция БД.doc
Скачиваний:
15
Добавлен:
02.08.2023
Размер:
556.54 Кб
Скачать

Лекция 6 инфологическое проектирование баз данных

План лекции

1. ЭТАПЫ ПРОЕКТИРОВАНИЯ БАЗЫ ДАННЫХ

2. ИНСТРУМЕНТАЛЬНЫЕ СРЕДСТВА ИНФОЛОГИЧЕСКОГО ПРОЕКТИРОВАНИЯ

1. ЭТАПЫ ПРОЕКТИРОВАНИЯ БАЗЫ ДАННЫХ

Жизненный цикл информационной системы включает 3 основные стадии: проектирование, программную реализацию, эксплуатацию.

На стадии проектирования ИС проектировщик выполняет следующую работу.

1. Обследует предметную область автоматизации (результат -"Техни-ческое задание").

2. Определяет объекты и перечень их атрибутов, для каждого объекта выделяет первичные ключи.

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

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

5. Выбирает ЭВМ и инструментальные средства (конкретную СУБД) для реализации.

6. Проверяет корректность проекта.

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

* Описать средствами СУБД и ввести в ЭВМ схемы всех отношений.

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

* Разработать программное обеспечение ПС для всех приложений.

* Заполнить ИС контрольными данными и отладить ее.

* Провести тестирование системы и скорректировать технологию ее обслуживания.

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

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

Рис. 3.1. Этапы проектирования БД

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

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

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

2. ИНСТРУМЕНТАЛЬНЫЕ СРЕДСТВА ИНФОЛОГИЧЕСКОГО ПРОЕКТИРОВАНИЯ

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

- инфологическая схема должна содержать все сведения о ПРОБЛ, необходимые для выполнения последующих этапов проектирования (включая количественные параметры, требования процессов обработки информации и пр.);

- инфологическая модель ПРОБЛ должна легко преобразовываться в модели баз данных для распространенных СУБД. Разрыв между возможностями этих моделей не должен быть настолько велик, чтобы возникли трудноразрешимые проблемы при их реализации;

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

Исходя из этих требований, целесообразно использовать в инфологическом проектировании модель типа "объекты - связи" (в другой терминологии "сущность - связи"). Такая модель определяется в терминах: атрибут, объект(сущность), связь (структурная или запросная),

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

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

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

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

Структурные связи устанавливают отношения подчиненности между объектами н определяют возможную навигацию между ними. Связь между объектами в зависимости от числа входящих в нее объектов характеризуется степенью: п = 2,3,.., к (бинарная, тернарная,..., К - арная).

Процессы над объектами предметной области задаются с помощью запросных связей. Запросная связь есть операция, на входе которой используется по одному экземпляру каждого исходного объекта, а на выходе - соответствующее подмножество экземпляров конечного объекта. Если количество исходных объектов в запросной связи равно единице, то она называется одномерной, а иначе- многомерной, Например, процесс состояний в выборке множества сотрудников заданной организации, может быть описан одномерной запросной связью ОРГАННЗАЦИЯ-?СОТРУДНИК.

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

1. Отображение 1:1("один к одному'). Здесь каждому экземпляру объекта А соответствует один и только один экземпляр объекта B и наоборот. Например, квартира ?? хозяин, номер зачетной книжки ?? студент.

2. Отображение 1 : М ("один ко многим"). Здесь одному экземпляру объекте А может соответствовать 0,1, или несколько экземпляров В , однако каждому экземпляру объекта В соответствует только один: экземпляр объекта А. Например, область ?? город.

3. Отображение М : 1 ("многие к одному") является обратным отображению 1 : М

4. Отображение М : N ("многие ко многим"). Здесь каждому экземпляру объекта А может соответствовать 0,1, несколько экземпляров В и наоборот. Например, дисциплина (курс ?? студент).

Связь моют быть однонаправленной (как простой, так и многозначной). Например:

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

Рис. 3.2. Пример графической диаграммы