Контрольная работа по "Информатике"

Вариант: 15

Задания: 9,14

 

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

14. Система представления информации в WWW.  Типы Web-документов (статические и динамические страницы). Понятие формы в HTML-документах. Скрипты и использование HTML-технологии для создания интерфейсов информационных систем.

 

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

 

 

 

1.1 Инфологическое моделирование

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

- таблиц, которые будут  входить в базу данных,

- столбцов, принадлежащих  каждой таблице,

- взаимосвязей между таблицами  и столбцами.

Часто при обсуждении вопросов проектирования реляционных баз  данных почти все внимание уделяется  применению правил нормализации. В  ходе нормализации обеспечивается защита целостности данных путем устранения дублирования данных. В результате таблица, которая первоначально казалась «имеющей смысл», разбивается на две или более связанных таблиц, которые могут быть «собраны вместе» с помощью операции объединения. Этот процесс называется декомпозицией без потерь (non-loss decomposition) и просто означает разделение таблицы на несколько меньших таблиц без потери информации. Нормализация наиболее полезна для проверки созданной вами структуры

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

1. Исследования информационной  среды для моделирования. 

• Откуда поступает информация и в каком виде?
• Как она будет вводиться в систему и кто этим будет заниматься?
• Как часто она изменяется?
• Какие параметры системы будут наиболее критическими с точки зрения времени реакции на запрос и надежности?

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

Кому она будет предназначаться.

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

3. В ходе работы обязательно  должен создаваться макет таблиц  и связей между ними, называемый  структурой данных (data structure), или диаграммой зависимостей между объектами (E-R diagram).

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

5. Затем должны быть  рассмотрены зависимости между  объектами. 

Имеются ли зависимости типа один-ко-многим (один заказчик может  иметь множество выписанных счетов, но каждый счет может быть выписан  только на одного заказчика) или многие-ко-многим?

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

6. Анализ структуры базы  данных с точки зрения правил  нормализации для поиска логических  ошибок. Исправление всех отклонений  от нормальных форм или обоснование  решения отказаться от выполнения  ряда правил нормализации в  интересах простоты освоения  или производительности. Документирование  причины таких решений.

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

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

Для технической реализации цели с учетом поставленных требований была выбрана система управления базами данных «Microsoft Access».

Данная СУБД была выбрана  по следующим причинам:

- простота средств реализации,

- легкость освоения инструментарием  разработчика (VBA),

- наглядность визуализации  информации.

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

Связи между таблицами  можно разбить на четыре базовых  реляционных типа с отношениями:

- один-к-одному;

- один-ко-многим;

- многие-к-одному;

- многие-ко-многим.

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

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

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

Сущность имеет имя, уникальное в пределах модели. При этом имя  сущности - это имя типа, а не конкретного  экземпляра.

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

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

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

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

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

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

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

Между двумя сущностям, например, А и В возможны четыре вида связей.

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

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

Так как между двумя  сущностями возможны связи в обоих  направлениях, то существует еще два  типа связи МНОГИЕ-К-ОДНОМУ (М:1) и  МНОГИЕ-КО-МНОГИМ (М:N).

 

РЕЛЯЦИОННЫЙ ПОДХОД К ПОСТРОЕНИЮ ИНФОЛОГИЧЕСКОЙ МОДЕЛИ

Понятие информационного  объекта

 

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

 

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

 

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

 

Пример 15.8. На рис. 15.14 представлен  пример структуры и экземпляров  информационного объекта Студент.

 

В информационном объекте  Студент ключом является реквизит Номер (¦ личного дела), к описательным реквизитам относятся: Фамилия (Фамилия студента), Имя (Имя студента). Отчество (Отчество студента). Дата (Дата рождения). Группа (N группы). Если отсутствует реквизит Номер, то для однозначного определения характеристик конкретного студента необходимо использование составного ключа из трех реквизитов: Фамилия + Имя + Отчество.

Структура 

Номер 

Фамилия 

Имя 

Отчество 

Дата 

Группа

 

Экземпляры инф. объекта  Студент 

16493 

Сергеев 

Петр 

Михайлович 

01.01.76 

111

 

16593 

Петрова 

Анна 

Владимировна 

15.03.75 

112

 

16693 

Анохин 

Андрей 

Борисович 

14.04.76 

111

 

 

Рис. 15.14. Пример структуры  и экземпляров информационного  объекта

 

Пример 15.9. Hа рис.15.15 изображен пример компактного представления информационного объекта Студент с обозначением имени объекта, ключа и указанием максимально возможного числа экземпляров записи.

Студент============== 150

 

Номер

 

 

Рис. 15.15. Пример компактного  представления информационного  объекта

 

Пример 15.10. Пример представления  информационногообъектаСтудент в видеграфа на рис. 15.16.

 

 

 

Рис. 15.16. Пример представления  информационного объекта в виде графа

НОРМАЛИЗАЦИЯ ОТНОШЕНИЙ

 

Понятие нормализации отношений

 

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

 

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

 

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

 

В.Коддом выделены три нормальные формы отношений и предложен механизм, позволяющий любое отношение преобразовать к третьей (самой совершенной)•нормальной форме [2].

Первая нормальная форма

 

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