<< Вернуться у выбору материала

Тема № 3. Данные

Введите ваш запрос для начала поиска.

Для того, чтобы вовсе не платить больше купить елку на заказ лучше в интернете. . http://taxist.ru/ работа uber в москве.

3.1 Общие понятия и определения

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

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

Информацию можно определить, как объединение данных с конкретной целью или в конкретном контексте рис 3.1

Объединение данных с конкретной целью

Рис. 3.1 Объединение данных

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

Атрибут – смысл или отображение свойства некоторого объекта, процесса или явления.

Значение может состоять из одного конкретного значения, например возраст - атрибут 18 лет или содержать другие атрибуты и соответствующие им значения.

3.1 Концепция трех схем хранения данных

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

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

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

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

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

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

1. согласована с инфраструктурой предметной области;

2. стабильна, при ее расширении новые данные определяются без изменения ранее определенных;

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

На рис 3.2 показано ее место в схеме определения данных.

Внешняя схема
Концептуальная схема
Внутренняя схема

Рис 3.2 Концепция трех схем

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

Остановимся на основных понятиях концептуальной схемы данных, они включают в себя понятия:

1.Сущности

2.Отношения

3. Атрибуты / ключи

Сущность представляет множество реальных или абстрактных объектов, обладающих атрибутами или характеристиками. (См. Тема2)

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

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

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

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

Правила:

1. Каждая сущность должна иметь уникальное имя

2. Сущность обладает одним или несколькими атрибутами, которые принадлежат сущности или наследуются через отношения.

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

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

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

Отношения связи.

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

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

Один к одному (1:1).

Один ко многим (1:М).

Многие ко многим (М:М).

Связь один к одному (1:1) предполагает, что в каждый момент времени одному экземпляру информационного объекта А соответствует не более одного экземпляра объекта В и наоборот. Графически рис.3.2 иллюстрирует данный тип отношений.

Графическое отображение реального отношения один к одному

Рис 3.3 Графическое отображение реального отношения один к одному.

Примером связи 1:1 может служить СТУДЕНТ и СЕССИЯ.

СТУДЕНТСЕССИЯ

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

При связи один ко многим (1:М), одному экземпляру информационного объекта А соответствует 0,1, или более экземпляров объекта В. но каждый экземпляр объекта В связан не более чем с 1 экземпляром объекта А.

Графически данное соотношение представлено на рис.3.4

Графическое отображение реального отношения один ко многим

Рис 3.4 Графическое отображение реального отношения один ко многим

Примером связи 1:М служит связь между информационными объектами

ИНСТИТУТ ПРЕПОДОВАТЕЛЬ

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

Связь многие ко многим (М:М) предполагает, что в каждый момент времени одному экземпляру информационного объекта А соответствует 0,1 или более экземпляров объекта В или наоборот. На рис 3.5 представлено графически данное соотношение.

Графическое отображение реального отношения один ко многим

Рис 3.5 Графическое отображение реального отношения один ко многим.

Примером данного отношения служит связь между информационным объектом СТУДЕНТ И ПРЕПОДАВАТЕЛЬ

СТУДЕНТ ПРЕПОДОВАТЕЛЬ

Кроме того отношения связи подразделяются на:

Специфические отношения связи, это отношения при котором каждая сущность или экземпляр сущности, называемой родительской ассоциируется с произвольным количеством экземпляров другой сущности, называемой потомком. Например, сущность ПОКУПАТЕЛЬ и ЗАКАЗ_НА_ПОКУПКУ. Отношения могут дополнительно определяться указанием мощности отношений.

Среди специфических отношений можно выделить отношения

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

Не идентифицирующие связь – если экземпляр сущности может быть однозначно, идентифицироваться без знания связанного с ним экземпляра сущности родитель. Например, ПОКУПАТЕЛЬ и ЗАКАЗ_НА_ПОКУПКУ. Хотя между этими сущностями существует отношения зависимого существования, заказы на покупку могут идентифицироваться номерами заказов без идентификации покупателя.

Отношению дается имя, выраженное грамматическим оборотом. Имя отношения формируется с токи зрения родителя. Например, ПОКУПАТЕЛЬ отвечает за ЗАКАЗ_НА_ПОКУПКУ.

Отношения категоризации. Некоторые реально существующие объекты являются категориями других реально существующих объектов, то некоторые сущности являются категориями других сущностей. Например, категория сущности СЛУЖАЩИЙ могут подразделяться на ШТАТНЫЙ СЛУЖАЩИЙ и ПОЧАСОВИК. Сущности – категории всегда являются взаимоисключающими.

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

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

3.3 Технология анализа предметной области

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

Анализ предметной области целесообразно разбить на три этапа и сводится к:

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

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

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

3.3.1 Анализ концептуальных требований и информационных потребностей

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

Рассмотрим примерный состав вопросов при разработке ИС предназначенной для учета успеваемости студентов:

1) Какой институт рассматривается?

2) Сколько факультетов в институте?

3) Сколько кафедр в институте?

4) Какие преподаватели работают на кафедрах?

5) Какие дисциплины преподает каждый преподаватель?

6) Сколько специальностей на факультете?

7) Сколько семестров обучаются студенты по каждой специальности?

8) Какие предметы читаются в семестре?

9) Сколько групп обучается?

10) Сколько студентов в каждой группе?

11) Какие экзамены сдает студент?

12) Какие оценки он получил по каждой специальности?

13) Кому назначена стипендия?

14) Размер стипендии?

15) Кого из студентов отчислили из института?

16) Какие дисциплины должен пересдать студент в начале следующего семестра?

Далее проектировщик выбирает по имеющимся документам необходимые информационные объекты.

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

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

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

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

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

3. Какие характеристики необходимо выделить, для решения того или иного класса задач?

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

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

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

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

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

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

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

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

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

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

Одной из распространенных моделей концептуальной схемы является модель «сущность - связь». Основными конструкциями данной модели являются сущности и связи.

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

Экземпляр сущности - конкретный объект.

Например:

сущность (объект) - институт экземпляр сущности -СГУТиКД.

Сущность принято определять атрибутами - поименованными характеристиками. Например:

сущность студент

атрибуты: ФИО, Группа,

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

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

Выберем следующие сущности:

УНИВЕРСИТЕТ, ИНСТИТУТ, СТУДЕНТ, ПРЕПОДАВАТЕЛЬ, ДИСЦИПЛИНА.

В данном примере можно выделить сущность ЭКЗАМЕН или ВЕДОМОСТЬ, но можно не выделять, а сформировать ведомость из имеющихся данных посредствам связей.

Зададим каждую сущность набором атрибутов, например:

УНИВЕРСИТЕТ (название, подчиненность, адрес, телефон, ФИО ректора).

ИНСТИТУТ (название, код специальности, группы, декан).

СТУДЕНТ (ФИО, группа, курс, номер семестра).

ПРЕПОДАВАТЕЛЬ (ФИО, должность, звание, институт, читаемые дисциплины).

ДИСЦИПЛИНА (название, число часов, виды занятий, номер семестра, итоговая аттестация)

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

Название связи Сущность 1 Сущность 2 Сущность 3
учится студент институт
изучает студент дисциплина
имеет университет институт
работает преподаватель институт
преподает преподаватель дисциплина
экзамен студент дисциплина преподаватель

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

Концептуальная схема БД "Успеваемость» представлена на рис. 2.5

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

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

1. Значение атрибута "курс" (сущность - СТУДЕНТ) лежит в интервале 1-6.

4. Значение атрибута "семестр" (сущность - СТУДЕНТ, ДИСЦИПЛИНА) в интервале 1-12.

5. Значение атрибута "число часов" (сущность - ДИСЦИПЛИНА) лежит в интервале 1-300.

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

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

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

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

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

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

12. Ключи: название института, название университета, ФИО и группа студента, ФИО и преподавателя, название дисциплины.

Концептуальная схема БД - успеваемость

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

Для уменьшения нежелательных характеристик БД к схемам отношений применяют процедуры нормализации. Рассмотрим понятие функциональной зависимости. Пусть R (A1, A2,...,Ai,...,An) - схема отношения R. Обозначим через Dom (Aj) множество возможных состояний атрибута Aj. Будем говорить, что атрибуты Ai и AJ отношения К связаны функциональной зависимостью, т.е. f: Dom (Ai) -> Dom (Aj), которую будем понимать как множество упорядоченных пар

{ <а, в> / а€ Dom (Ai), b€ Dom (Aj) },

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

При этом в каждый момент элементу а€ Dom (Ai) соответствует не более

одного элемента b€ Dom (Aj).

Функциональная связь доменов инвариантна по отношению к схеме конкретного отношения. Понятие функциональной зависимости позволяет определить ключ отношения. Пример 1.

Выявим функциональные зависимости в отношении БД "Учеба". R учеба (факультет, группа, дисциплина, вид занятий, преподаватель, квалификация преподавателя)

f: (дисциплина, вид занятий) -> квалификация преподавателя преподаватель -> квалификация преподавателя

группа -> факультет преподаватель -> факультет

Фиксация функциональных зависимостей в схеме отношения ограничивает число возможных состояний схемы.

3.3.4 Логическое проектирование

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

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

1. Выбор конкретной СУБД.

2. Отображение концептуальной схемы на логическую схему.

3. Выбор ключей.

4. Описание языка запросов.

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

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

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

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

1. Общие характеристики:

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

2. Управление файлами и поиск:

тип связи; модификация нескольких файлов; двунаправленное соединение таблиц; ЯМД; тип поиска.

3. Средства поддержки приложений:

каталог данных; генератор приложений; процедурный язык; подпрограммы; макросы; отладчик; система поддержки исполнения; шифровка программ и данных; разграничение доступа; графика; графика цветная; текстовый редактор; экранный художник; статистика.

4. Ввод и поддержание целостности:

управление с помощью команд; управление с помощью меню; проверка целостности по таблице; проверка уникальности ключа; проверка по дате; независимость данных.

5.Отчеты:

отчеты по нескольким файлам; сохранение форматов отчета; выдача отчета на экран; выдача отчета на магнитный носитель; вычисляемые поля; группы; переопределение формата даты; формат "почтовой карточки"; заголовки отчетов; генератор отчетов; окончание отчета; итоговые поля; максимальная ширина отчета; отчет в матричной форме.

6.Операционная среда:

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

7.Дополнительные сведения:

наличие сетевого варианта; стоимость; примечание; источники.

При отображении концептуальной схемы на реляционную модель, каждый прямоугольник схемы отображается в таблицу. Отобразим, например сущность ПРЕПОДАВАТЕЛЬ описываемую атрибутами ФИО, должность, звание, кафедра, стаж, в виде таблицы.

ПРЕПОДАВАТЕЛЬ

ФИО Должность Звание Институт Дисциплина

Определим структуру каждой таблицы, то есть типы и размеры полей

Признак ключа Поле Тип поля Размер поля
ключ ФИО текстовый 21
Должность текстовый 15
Звание текстовый 10
Ключ Институт текстовый 20
Дисциплина текстовое 15

Выводы

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

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

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

Логическая модель отражает логические связи между элементами данных вне зависимости от их содержания и среды хранения.

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

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

В современных СУБД выполнение задач физического проектирования осуществляется автоматически.

Рейтинг@Mail.ru