3. Редактирование и сортировка слайдов

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

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

62) Настройка презентации Для этого на вкладке, появляющейся после выполнения команды Меню \ показ слайдов \ настройка презентации Нужно задать способ показа, например, автоматический, полный экран параметры речевого сопровождения, номера слайдов, которые нужно показывать, параметр смены слайдов: вручную или по времени, можно также задать резолюцию, с которой нужно показывать презентацию. Остальные параметры пользователь легко выберет сам, если он сможет добраться до их настройки. В заключение не забудьте сохранить файл Презентация сохраняется в виде файла. Существуют различные подходы к сохранению презентации в зависимости от цели, с которой делается сохранение. Самые распространенные варианты: -сохранение с возможностью последующего развития и модификации (формат .ppt) -сохранение для показа (формат .pps) -сохранение презентации для публикации в Интернет (формат .html или .mht) -сохранение слайдов в виде отдельных графических файлов (форматы графических файлов) -сохранение в качестве шаблона для разработки других презентаций. В том случае, когда требуется опубликовать презентацию в Интернет, обеспечивая тем самым широкий доступ к презентации всем пользователям сети, следует сохранить презентацию в специальном формате .htm (.html) или .mht (.mhtl). Для публикации презентации в Интернет в меню Файл-Сохранить как web-страницу. Последним шагом в подготовке презентации является задание параметров показа презентации. Данные параметры собраны в окне Настройка демонстрации. Здесь определяется: -будет ли демонстрация осуществляться в автоматическом режиме или под управлением человека (докладчика или пользователя) -будет ли демонстрация делаться со звуковым сопровождением или без него -нужно ли использовать назначенные эффекты анимации -какие слайды будут включены в показ -будет ли делаться продвижение по слайдам в соответствии с назначенным временем или по нажатию клавиш с каким качеством демонстрировать слайды. Программой предусмотрены три основные режима демонстрации: -Режим управления докладчиком -Режим управления пользователем -Автоматический режим Прежде чем приступить к написанию программ на VBA, воспользуемся простой возможностью создания программы (макроса) на языке VBA с использованием MacroRecorder(это программа, записывающая макросы). Макрос — это именованная последовательность заданных пользователем команд и действий, хранящаяся в форме программы на языке VBA. Основное назначение макросов — автоматизация работы пользователя. Кроме этого, созданный код макроса может служить основой для дальнейших разработок. При записи макроса запоминаются все действия пользователя, будь то нажатие клавиши или выбор определенной команды меню, которые автоматически преобразуются в программный код на языке VBA. Каждому макросу дается имя, а для быстрого запуска макроса можно создать или присвоить ему “горячую” клавишу (клавишу, по нажатию на которую будет производиться запуск макроса). После запуска макрос будет автоматически выполнен тем приложением, в котором он создан и запущен. При выполнении макроса компьютер воспроизведет все действия пользователя

63) Восприятие реального мира можно соотнести с последовательностью разных, хотя иногда и взаимосвязанных, явлений. С давних времен люди пытались описать эти явления (даже тогда, когда не могли их понять). Такое описание называют данными.

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

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

Интерпретация
Номер рейса	Дни недели	Пункт отправления	Время вылета	Пункт назначения	Время прибытия	Тип самолета	Стоимость билета
Данные
138	2_4_7	Баку	21.12	Москва	0.52	ИЛ-86	115.00
57	3_6	Ереван	7.20	Киев	9.25	ТУ-154	92.00
1234	2_6	Казань	22.40	Баку	23.50	ТУ-134	73.50
242	1 по 7	Киев	14.10	Москва	16.15	ТУ-154	57.00
86	2_3_5	Минск	10.50	Сочи	13.06	ИЛ-86	78.50
137	1_3_6	Москва	15.17	Баку	18.44	ИЛ-86	115.00
241	1 по 7	Москва	9.05	Киев	11.05	ТУ-154	57.00
577	1_3_5	Рига	21.53	Таллин	22.57	АН-24	21.50
78	3_6	Сочи	18.25	Баку	20.12	ТУ-134	44.00
578	2_4_6	Таллин	6.30	Рига	7.37	АН-24	21.50 Рис. 1.1. К разделению данных и их интерпретации

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

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

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

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

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

Для иллюстрации обратимся к примеру, приведенному в книге: У.Девис, Операционные системы, М., Мир, 1980:

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

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

64) CALS — Continuous Acquisition and Life-Cycle Support.

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

1 Этап обследование (предварительное и полное)

Кем выполняется аналитик Результат инфологическая модель, ТЗ на проектирование

2 Этап проектирование Кем выполняется проектировщик Результат даталогическая модель, проект 3 Этап кодирование Кем выполняется кодировщик Результат физическая модель 4 Этап опытная эксплуатация Кем выполняется заказчик Результат акт результатов о.э. 5 Этап доработка и внедрение в промышленную эксплуатацию Кем выполняется все

65) Сущность — любой различимый объект (объект, который мы можем отличить от другого), информацию о котором необходимо хранить в базе данных. Сущностями могут быть люди, места, самолеты, рейсы, вкус, цвет и т.д. Необходимо различать такие понятия, как тип сущности и экземпляр сущности.  Атрибут — поименованная характеристика сущности. Его наименование должно быть уникальным для конкретного типа сущности, но может быть одинаковым для различного типа сущностей (например, ЦВЕТ может быть определен для многих сущностей: СОБАКА, АВТОМОБИЛЬ, ДЫМ и т.д.). Атрибуты используются для определения того, какая информация должна быть собрана о сущности.  Ключ — минимальный набор атрибутов, по значениям которых можно однозначно найти требуемый экземпляр сущности. Минимальность означает, что исключение из набора любого атрибута не позволяет идентифицировать сущность по оставшимся. Связь — ассоциирование двух или более сущностей. Если бы назначением базы данных было только хранение отдельных, не связанных между собой данных, то ее структура могла бы быть очень простой. Однако одно из основных требований к организации базы данных — это обеспечение возможности отыскания одних сущностей по значениям других, для чего необходимо установить между ними определенные связи. А так как в реальных базах данных нередко содержатся сотни или даже тысячи сущностей, то теоретически между ними может быть установлено более миллиона связей. Наличие такого множества связей и определяет сложность инфологических моделей.

66) В конце 60-х годов появились работы, в которых обсуждались возможности применения различных табличных даталогических моделей данных, т.е. возможности использования привычных и естественных способов представления данных. Наиболее значительной из них была статья сотрудника фирмы IBM д-ра Э.Кодда (Codd E.F., A Relational Model of Data for Large Shared Data Banks. CACM 13: 6, June 1970), где, вероятно, впервые был применен термин "реляционная модель данных".

Будучи математиком по образованию Э.Кодд предложил использовать для обработки данных аппарат теории множеств (объединение, пересечение, разность, декартово произведение). Он показал, что любое представление данных сводится к совокупности двумерных таблиц особого вида, известного в математике как отношение – relation (англ.) [3, 7, 9].

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

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

Смысл доменов состоит в следующем. Если значения двух атрибутов берутся из одного и того же домена, то, вероятно, имеют смысл сравнения, использующие эти два атрибута (например, для организации транзитного рейса можно дать запрос "Выдать рейсы, в которых время вылета из Москвы в Сочи больше времени прибытия из Архангельска в Москву"). Если же значения двух атрибутов берутся из различных доменов, то их сравнение, вероятно, лишено смысла: стоит ли сравнивать номер рейса со стоимостью билета?

Отношение на доменах D1, D2, ..., Dn (не обязательно, чтобы все они были различны) состоит из заголовка и тела. На рис. 3.1 приведен пример отношения для расписания движения самолетов (рис. 1.1).

Заголовок (на рис. 1.1 он назывался интерпретацией) состоит из такого фиксированного множества атрибутов A1, A2, ..., An, что существует взаимно однозначное соответствие между этими атрибутами Ai и определяющими их доменами Di (i=1,2,...,n).

Тело состоит из меняющегося во времени множества кортежей, где каждый кортеж состоит в свою очередь из множества пар атрибут-значение (Ai:Vi), (i=1,2,...,n), по одной такой паре для каждого атрибута Ai в заголовке. Для любой заданной пары атрибут-значение (Ai:Vi) Vi является значением из единственного домена Di, который связан с атрибутом Ai.

Степень отношения – это число его атрибутов. Отношение степени один называют унарным, степени два – бинарным, степени три – тернарным, ..., а степени n – n-арным. Степень отношения "Рейс" (рис. 1.1) – 8.

Кардинальное число или мощность отношения – это число его кортежей. Мощность отношения "Рейс" равна 10. Кардинальное число отношения изменяется во времени в отличие от его степени.

Поскольку отношение – это множество, а множества по определению не содержат совпадающих элементов, то никакие два кортежа отношения не могут быть дубликатами друг друга в любой произвольно-заданный момент времени. Пусть R – отношение с атрибутами A1, A2, ..., An. Говорят, что множество атрибутов K=(Ai, Aj, ..., Ak) отношения R является возможным ключом R тогда и только тогда, когда удовлетворяются два независимых от времени условия:

1. Уникальность: в произвольный заданный момент времени никакие два различных кортежа R не имеют одного и того же значения для Ai, Aj, ..., Ak.

2. Минимальность: ни один из атрибутов Ai, Aj, ..., Ak не может быть исключен из K без нарушения уникальности.

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

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

Отношение – Таблица (иногда Файл), Кортеж – Строка (иногда Запись), Атрибут – Столбец, Поле.

При этом принимается, что "запись" означает "экземпляр записи", а "поле" означает "имя и тип поля".

67)…

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

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

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

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

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

1) первая нормальная форма (1 NF);

2) вторая нормальная форма (2 NF);

3) третья нормальная форма (3 NF);

4) нормальная форма Бойса – Кодда (BCNF);

5) четвертая нормальная форма (4 NF);

6) пятая нормальная форма, или нормальная форма проекции-соединения (5 NF или PJ/NF).

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

Основные свойства нормальных форм состоят в следующем:

1) каждая следующая нормальная форма в некотором смысле лучше предыдущей нормальной формы;

2) при переходе к следующей нормальной форме свойства предыдущих нормальных форм сохраняются.

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

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

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

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

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

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

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

Итак, вариант 1 схемы базы данных.

Сессия (№ зачетной книжки, Фамилия, Имя, Отчество, Предмет, Оценка)

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

Primary key (№ зачетной книжки, Предмет);

Также в этом отношении задана система функциональных зависимостей:

{№ зачетной книжки} → {Фамилия, Имя, Отчество};

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

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

Эта процедура основывается на том, что единственными функциональными зависимостями в любой таблице должны быть зависимости вида K->F, где K – первичный ключ, а F – некоторое другое поле. Заметим, что это следует из определения первичного ключа таблицы, в соответствии с которым K->F всегда имеет место для всех полей данной таблицы. "Один факт в одном месте" говорит о том, что не имеют силы никакие другие функциональные зависимости. Цель нормализации состоит именно в том, чтобы избавиться от всех этих "других" функциональных зависимостей, т.е. таких, которые имеют иной вид, чем K->F.

Если воспользоваться рекомендацией п. 4.5 и подменить на время нормализации коды первичных (внешних) ключей на исходные ключи, то, по существу, следует рассмотреть лишь два случая:

1. Таблица имеет составной первичный ключ вида, скажем, (К1,К2), и включает также поле F, которое функционально зависит от части этого ключа, например, от К2, но не от полного ключа. В этом случае рекомендуется сформировать другую таблицу, содержащую К2 и F (первичный ключ – К2), и удалить F из первоначальной таблицы:

Заменить T(K1,K2,F), первичный ключ (К1,К2), ФЗ К2->F

на T1(K1,K2), первичный ключ (К1,К2),

и T2(K2,F), первичный ключ К2.

2. Таблица имеет первичный (возможный) ключ К, не являющееся возможным ключом поле F1, которое, конечно, функционально зависит от К, и другое неключевое поле F2, которое функционально зависит от F1. Решение здесь, по существу, то же самое, что и прежде – формируется другая таблица, содержащая F1 и F2, с первичным ключом F1, и F2 удаляется из первоначальной таблицы:

Заменить T(K,F1,F2), первичный ключ К, ФЗ F1->F2

на T1(K,F1), первичный ключ К,

и T2(F1,F2), первичный ключ F1.

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

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

Пример 4.1. Применим рассмотренные правила для полной нормализации универсального отношения "Питание" (рис. 4.2).

Шаг 1. Определение первичного ключа таблицы.

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

Блюдо, Дата_Р, Продукт, Поставщик, Город, Дата_П.

Шаг 2. Выявление полей, функционально зависящих от части состваного ключа.

Поле Вид функционально зависит только от поля Блюдо, т.е.

Блюдо->Вид.

Аналогичным образом можно получить зависимости:

Блюдо->Рецепт

(Блюдо, Дата_Р)->Порций

Продукт->Калорийность

(Блюдо, Продукт)->Вес

Город->Страна

(Поставщик, Город, Дата_П)->Цена

Шаг 3. Формирование новых таблиц.

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

Блюда (Блюдо, Вид)

Рецепты (Блюдо, Рецепт)

Расход (Блюдо, Дата_Р, Порций)

Продукты (Продукт, Калорийность)

Состав (Блюдо, Продукт, Вес (г))

Города (Город, Страна)

Поставки (Поставщик, Город, Дата_П, Вес (кг), Цена).

Шаг 4. Корректировка исходной таблицы.

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

Поставщики (Поставщик, Город),

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

71) Программа ERwin предназначена для построения ИЛМ с использованием методологии IDEF1X и автоматической генерации соответствующей ДЛМ с учетом особенностей выбранной СУБД. Результатом генерации ДЛМ является схема БД, представленная на языке SQL, и созданные таблицы, входящие в БД. ERwin может генерировать ДЛМ для более чем 20 реляционных и нереляционных СУБД. Для обозначения моделей данных ERwin использует терминологию, отличную от рассмотренной в лекциях: ИЛМ именуется логической (Logical) моделью, а ДЛМ - физической (Physical) моделью. Создание БД с помощью ERwin начинается с построения логической модели. После описания логической модели проектировщик выбирает необходимую СУБД, и ERwin автоматически создает соответствующую физическую модель. На основе физической модели ERwin может сгенерировать схему БД на языке SQL и сформировать таблицы, образующие БД. Этот процесс называется прямым проектированием (Forward Egineering) и обеспечивает масштабируемость: создав одну логическую модель, можно сгенерировать физические модели для любой СУБД, поддерживаемой программой ERwin. Кроме того, ERwin способен для существующей БД воссоздать физическую и логическую модели, т.е. обеспечить обратное проектирование (Reverse Engineering). На основе полученной логической модели можно сгенерировать физическую модель для другой СУБД и затем сформировать новую БД. Следовательно, ERwin позволяет решить задачу по переносу структуры БД с одной СУБД на другую. После запуска программы ERwin появляется окно программы (рис.4) со строкой главного меню, панелью инструментов и рабочей областью, в которой находится палитра инструментов с кнопками. Вид палитры инструментов (ERwin Toolbox) зависит от выбора логической или физической модели, который осуществляется с помощью списка, расположенного в правой части панели инструментов

72) Интерфейс выполнен в стиле Windows-приложений, достаточно прост и интуитивно понятен. Рассмотрим кратко основные функции ERwin по отображению модели.

Каждому уровню отображения модели соответствует своя палитра инструментов. На логическом уровне палитра инструментов имеет следующие кнопки:

• кнопку указателя (режим мыши) — в этом режиме можно установить фокус на каком-либо объекте модели;

• кнопку внесения сущности;

• кнопку категории (категория, или категориальная связь, — специальный тип связи между сущностями, которая будет рассмотрена ниже);

• кнопку внесения текстового блока;

• кнопку перенесения атрибутов внутри сущностей и между ними;

• кнопки создания связей: идентифицирующую, "многие-ко-многим" и неидентифицирующую.

На физическом уровне палитра инструментов имеет:

• вместо кнопки категорий — кнопку внесения представлений (view);

• вместо кнопки связи "многие-ко-многим" — кнопку связей представлений.

Для создания моделей данных в ERwin можно использовать две нотации: IDEFIX и IE (Information Engineering). В дальнейшем будет рассматриваться нотация IDEFIX.

ERwin имеет несколько уровней отображения диаграммы: уровень сущностей, уровень атрибутов, уровень определений, уровень первичных ключей и уровень иконок. Переключиться между первыми тремя уровнями можно с использованием кнопок панели инструментов. Переключиться на другие уровни отображения можно при помощи контекстного меню, которое появляется, если "кликнуть" по любому месту диаграммы, не занятому объектами модели. В контекстном меню следует выбрать пункт Display Level (ris20) и затем — необходимый уровень отображения.

73) Среди многочисленных средств Microsoft Access следует выделить средства для создания: таблиц и схем баз данных; запросов выборки, отбирающих и объединяющих данные нескольких таблиц в виртуальную таблицу, которая может использоваться во многих задачах приложения; запросов на изменение баз данных; экранных форм, предназначенных для ввода, просмотра и обработки данных в диалоговом режиме; отчетов, предназначенных для просмотра и вывода на печать данных из базы и результатов их обработки в удобном для пользователя виде. В СУБД поддерживаются различные модели данных. Список объектов Microsoft Access: Таблица — отношение поля — столбцы отношения, атрибуты; записи — кортежи; Запрос — объект, который позволяет пользователю получить нужные данные из одной или нескольких таблиц (QBE или SQL) Форма — объект, предназначенный в основном для ввода данных. Отчет — объект, предназначенный для создания документа, предназначенного для печати. Макрос — объект, содержащий несколько команд, которые, по мнению разработчика, должен выполнить Access в ответ на определенное событие. Модуль — объект, содержащий программы на Microsoft Access Basic, которые позволяют разбить процесс на более мелкие действия и обнаружить ошибки, которые невозможно обнаружить с помощью макросов.

74) Internet - это глобальная компьютерная сеть, которая состоит из отдельных компьютерных сетей меньшего масштаба. Помимо этого к Internet можно свободно подключать отдельные компьютеры, будь то домашний персональный компьютер или суперкомпьютер, который находится в большой организации. Основная задача Internet, как и любой другой вычислительной сети, - это передача данных от одного компьютера к другому.Главное свойство Internet состоит в том, что если в сеть подключается новый абонент, то ему становится доступна информация всей сети. И, наоборот, всем остальным абонентам Internet становится доступна информация и ресурсы его компьютера.Особенность сети Internet заключается в том, что фактически Internet, как глобальная мировая компьютерная сеть, не имеет своего владельца, т.е. она ни кому не принадлежит. Она существует просто потому, что в этом заинтересованы те, кто эксплуатирует эту сеть. Хотя отдельные вычислительные сети, которые подключены к Internet, имеют своих конкретных владельцев.Всемирная сеть Internet состоит из нескольких систем, которые могут функционировать как вместе, так и независимо друг от друга. Рассмотрим подробно эти системы.

World Wide Web (WWW - дословно переводится как всемирная паутина) - это глобальная гипертекстовая система документов, связанных электронными ссылками. WWW позволяет перемещаться между различными документами, используя гиперссылки, причем географическое расположение компьютеров, на которых хранится информация, не имеет значения. Гиперссылка - это электронная ссылка в документе, связывающая его с другим документом. Гиперссылка в тексте обычно обозначается в виде подчеркнутого текста, выделенного другим цветом. При наведении мышки на гиперссылку она меняет свою форму и по щелчку происходит загрузка того документа, с которым связана данная ссылка. Электронная почта (E-mail) - система электронных сообщений между компьютерами. В отличие от WWW работа с электронной почтой может происходить в режиме off-line, т.е. в режиме отключения от Internet. Подключение к Internet необходимо только для отправки и принятия сообщений, а чтение и создание сообщений происходит без соединения с Internet.master - имя абонента;@ - определитель почтового адреса в Internet;primer.ru - имя сервера, на котором располагается "почтовый ящик" пользователя.Электронные конференции (usenet) - это система, с помощью которой любой пользователь сети Internet может сделать свои сообщения доступным всем остальным пользователям.FTP (File Transfer Protocol - протокол передачи файлов) — система, позволяющая копировать на компьютер файлы с любого другого компьютера, подключенного к Internet. FTP-серверы представляют собой как бы каталоги, содержащие тысячи файлов с разнообразной информацией, включая программы, звуковые файлы, рисунки, видеоизображения и т.д. FTP-серверы можно просматривать, используя стандартные браузеры Internet Explore и Netscape Navigator.VON (Voice On the Net) - это система общения голосом в сети, которая позволяет разговаривать пользователям Internet. Для этого у пользователя должны быть звуковая плата, микрофон и звуковые колонки (наушники). Качество звука в сети Internet пока еще хуже, чем в обычной телефонной сети. Однако это дешевый способ поговорить с другим человеком, который находится за тысячи километров.Telnet - система, позволяющая подключатся к другим компьютерам в сети и запускать на них программы. С помощью этой системы ресурсы одного компьютера могут быть использованы для увеличения возможностей другого компьютера. Telnet используется, как правило, специалистами, хорошо владеющими технологиями Internet.