Краткая теория вопроса
Информационная система (ИС) — программно-аппаратный комплекс, предназначенный для хранения и обработки информации о какой-либо предметной области.
Процесс создания ИС делится на ряд этапов. Обычно выделяют следующие этапы создания ИС:
- формирование требований к системе (анализ),
- проектирование,
- реализация,
- тестирование,
- ввод в действие,
- эксплуатация и сопровождение.
Важнейшим компонентом любой информационной системы является База данных (БД). База данных (Data Base) – структурированный, организованный набор данных, объединенный в соответствии с некоторой выбранной моделью и описывающий характеристики какой-либо физической или виртуальной системы.
Именно БД позволяет эксплуатировать ИС, выполнять ее текущее обслуживание, модифицировать и развивать её при модернизации предприятия (организации) или изменении информационных потоков, законодательства и форм отчетности предприятия (организации).
Согласно современной методологии, процесс создания ИС представляет собой процесс построения и последовательного преобразования ряда согласованных моделей на всех этапах жизненного цикла (ЖЦ) ИС. На каждом этапе ЖЦ создаются модели: организации, требований к ИС, проекта ИС, требований к приложениям и т. д.
Проектирование ИС охватывает три основные области:
- проектирование объектов данных (создание моделей данных), которые будут реализованы в базе данных;
- проектирование программ, экранных форм, отчетов, которые будут обеспечивать выполнение запросов к данным;
- учет конкретной среды или технологии, а именно: топологии сети, конфигурации аппаратных средств, используемой архитектуры (файл-сервер или клиент-сервер), параллельной обработки, распределенной обработки данных и т. п.
Модель – искусственный объект,представляющий собой отображение (образ) системы и её компонентов.
Модель данных (Data Model) – это графическое или текстовое представление анализа, который выявляет данные, необходимые организации с целью достижения ее миссии, функций, целей, стратегий, для управления и оценки деятельности организации. Модель данных выявляет сущности, домены (атрибуты) и связи с другими данными, а также предоставляет концептуальное представление данных и связи между данными.
Цель создания модели данных состоит в обеспечении разработчика ИС концептуальной схемой базы данных в форме одной модели или нескольких локальных моделей, которые относительно легко могут быть интегрированы в любую базу данных.
При создании моделей данных используется метод семантического моделирования. Семантическое моделирование основывается на значении структурных компонентов или характеристик данных, что способствует правильности их интерпретации (понимания, разъяснения). В качестве инструмента семантического моделирования используются различные варианты диаграмм сущность-связь (ER — Entity-Relationship) — ERD.
Существуют различные варианты отображения ERD, но все варианты диаграмм сущность-связь исходят из одной идеи — рисунок всегда нагляднее текстового описания. ER -диаграммы используют графическое изображение сущностей предметной области, их свойств (атрибутов), и взаимосвязей между сущностями.
Базовые понятия ERD
Сущность (таблица, отношение) — это представление набора реальных или абстрактных объектов (людей, вещей, мест, событий, идей, комбинаций и т. д.), которые можно выделить в одну группу, потому что они имеют одинаковые характеристики и могут принимать участие в похожих связях. Каждая сущность должна иметь наименование, выраженное существительным в единственном числе. Каждая сущность в модели изображается в виде прямоугольника с наименованием.
Можно сказать, что Сущности представляют собой множество реальных или абстрактных вещей (людей, объектов, событий, идей и т. д.), которые имеют общие атрибуты или характеристики.
Экземпляр сущности (запись, кортеж)- это конкретный представитель данной сущности.
Атрибут сущности (поле, домен) — это именованная характеристика, являющаяся некоторым свойством сущности.
Связь — это некоторая ассоциация между двумя сущностями. Одна сущность может быть связана с другой сущностью или сама с собою. Связи позволяют по одной сущности находить другие сущности, связанные с ней.
Каждая связь может иметь один из следующих типов связи:
Один-к-одному, многое-ко-многим, один-ко-многим.
Связь типа один-к-одному означает, что один экземпляр первой сущности (левой) связан с одним экземпляром второй сущности (правой). Связь один-к-одному чаще всего свидетельствует о том, что на самом деле мы имеем всего одну сущность, неправильно разделенную на две.
Связь типа многое-ко-многим означает, что каждый экземпляр первой сущности может быть связан с несколькими экземплярами второй сущности, и каждый экземпляр второй сущности может быть связан с несколькими экземплярами первой сущности. Тип связи много-ко-многим является временным типом связи, допустимым на ранних этапах разработки модели. В дальнейшем этот тип связи должен быть заменен двумя связями типа один-ко-многим путем создания промежуточной сущности.
Связь типа один-ко-многим означает, что один экземпляр первой сущности (левой) связан с несколькими экземплярами второй сущности (правой). Это наиболее часто используемый тип связи. Левая сущность (со стороны «один») называется родительской, правая (со стороны «много») — дочерней.
При разработке ER-моделей необходимо обследовать предметную область (организацию, предприятие) и выявить:
1) Сущности, о которых хранятся данные в организации (предприятии), например, люди, места, идеи, события и т.д., (будут представлены в виде блоков);
2) Связи между этими сущностями (будут представлены в виде линий, соединяющих эти блоки);
3) Свойства этих сущностей (будут представлены в виде имен атрибутов в этих блоках).
Задача: разработать информационную систему «Контингент студентов института».
Необходимо: изучить предметную область (образовательное учреждение) и процессы, происходящие в ней.
Для этого обследуем объект: знакомимся с нормативной документацией, опрашиваем работников института, изучаем существующий документооборот института, анализируем ситуацию и т.п.
В результате обследования определяем цель и задачи системы и формулируем постановку задачи.
Краткая постановка задачи: главная задача системы – сбор и обработка информации об основных участниках учебного процесса: студентах и преподавателях, формирование необходимых печатных форм (документов), используемых преподавателями в период зачётной недели и экзаменационной сессии, генерация сводных отчётов по результатам сессии для работников деканатов, института. При разработке системы следует учитывать, что она основывается на документации, поступающей из приёмной комиссии, деканатов и других подразделений института. Информация об успеваемости студентов должна накапливаться и храниться в течение всего периода обучения. В системе должен использоваться справочник специальностей и дисциплин (предметов), изучаемых студентами.
Таким образом, проектируемая система должна выполнять следующие действия:
- Хранить информацию о студентах и их успеваемости.
- На факультетах по определённой специальности печатать экзаменационные ведомости и другие документы.
Выделим все существительные в этих предложениях — это предполагаемые сущности и проанализируем их:
- Студент — явная сущность.
- Успеваемость — явная сущность.
- ? Факультет — нужно выяснить один или несколько факультетов в институте? Если несколько, то это — предполагаемая новая сущность.
- ? Специальность — нужно выяснить одна или несколько специальностей на факультете? Если несколько, то это — ещё одна сущность.
- Предмет — предполагаемая сущность.
На первоначальном этапе моделирования данных информационной системы явно выделены две основные сущности: Студент и Успеваемость.
Критерием успеваемости является наличие отметки о сдачи экзаменов.
Сразу возникает очевидная связь между сущностями — «студент сдаёт несколько экзаменов » и «экзамены сдаются каждым студентом». Явная связь Один-ко-многим. Первый вариант диаграммы выглядит так:
Мы знаем, что студенты учатся на факультетах, на определённой специальности и сдают экзамены по дисциплинам (предметам). Анализ предметной области показал, что студенты учатся на нескольких факультетах института по нескольким специальностях и сдают экзамены по определённому перечню предметов.
Исходя из этого, мы добавляем в ER-модель ещё несколько сущностей. В результате она будет выглядеть так:
На следующей стадии проектирования модели вносим атрибуты сущностей в диаграмму (предполагаем, что атрибуты выявлены на стадии обследования объекта и при анализе аналогов существующих систем) и получаем окончательный вариант ER— диаграммы:
Отметим, что предложенные этапы моделирования являются условными и нацелены на формирование общих представлений о процессе моделирования.
Разработанный выше пример ER-диаграммы является примером концептуальной диаграммы, не учитывающей особенности конкретной СУБД. На основе данной концептуальной диаграммы можно построить физическую диаграмму, которая будут учитывать такие особенности СУБД, как допустимые типы, наименования полей и таблиц, ограничения целостности и т.п.
Для преобразования концептуальной модели в физическую необходимо знать, что:
Каждая сущность в ER-диаграмме представляет собой таблицу базы данных.
Каждый атрибут становится колонкой (полем) соответствующей таблицы.
В некоторых таблицах необходимо вставить новые атрибуты (поля), которых не было в концептуальной модели — это ключевые атрибуты родительских таблиц, перемещённых в дочерние таблицы для того, чтобы обеспечить связь между таблицами посредством внешних ключей.
Выводы:
Семантическое моделирование данных основывается на технологии определения значения данных через их взаимосвязи с другими данными.
В качестве инструмента семантического моделирования используются различные варианты (нотации) диаграмм сущность-связь — (Entity-Relationship). Нотация — система условных обозначений, принятая в какой-либо области знаний или деятельности.
ER- диаграммы позволяют использовать наглядные графические обозначения для моделирования сущностей и их взаимосвязей. Основное достоинство метода состоит в том, модель строится методом последовательного уточнения и дополнения первоначальных диаграмм.
После создания концептуальной модели данных переходим к созданию физической модели средствами конкретной СУБД, а именно СУБД ACCESS. Для этого переходим к выполнению Практического задания №2
Приглашайте друзей на мой сайт
Создать диаграмму на основе сводной таблицы очень просто. Переключитесь в режим Сводная диаграмма (PivotChart View), и на экране появится сводная диаграмма, примерно такая, как на рис. 8.50.
Как и сводная таблица, она имеет поле фильтра — «Страна» (Country), которое отображается в левом верхнем углу экрана, поля строк и столбцов, которые здесь отображаются справа и снизу. Эта сводная диаграмма тесно связана с таблицей. Если вы переключитесь в режим сводной таблицы и измените ее структуру, это изменение будет отображено и на сводной диаграмме, и наоборот, если сейчас изменить структуру сводной диаграммы, то это изменение появится и на сводной таблице, когда вы вновь переключитесь в тот режим.
Рис. 8.50. Сводная диаграмма, построенная на основе сводной таблицы
Но можно создать диаграмму и непосредственно на базе запроса или таблицы. При этом одновременно будет создаваться и сводная таблица. Сводная таблица и сводная диаграмма — это две формы представления одних и тех же данных.
В качестве примера предлагается построить сводную диаграмму для запроса «Продажи по сотрудникам и странам» (Employee Sales by Country).
- Откройте этот запрос в режиме Конструктора.
- Запрос имеет два параметра: и , которые используются для фильтрации данных. Для сводной диаграммы эти параметры не нужны, поэтому сначала удалите выражение из строки Условие отбора (Criteria), затем откройте диалоговое окно Параметры (Query Parameters) (см. разд. «Запросы с параметрами»гл. 4) и удалите оба параметра.
- Щелкните по стрелке на кнопке Вид (View) панели инструментов и выберите из меню пункт Сводная диаграмма (PivotChart View). Появится окно, основную часть которого занимает область отображения диаграммы (рис. 8.51), ограниченная осями координат и размеченная линиями сетки. Кроме этого, видны область фильтра, которая играет ту же роль и расположена так же, как и в сводной таблице, область категорий и область рядов, которые соответствуют строкам и столбцам сводной таблицы. В область категорий переносятся поля, значения которых должны откладываться по оси X (горизонтальной), а в область рядов — поля, каждое значение которых соответствует одной серии точек или столбцов на диаграмме (в зависимости от типа диаграммы). Эти поля соответствуют полям столбцов на сводной диаграмме. В область данных помещаются поля, значения которых будут отображаться по оси Y (вертикальной) диаграммы.
Рис. 8.51. Макет сводной диаграммы
- Перетащите из списка полей в область фильтра поле «Страна» (Country), в область категорий — поля «Фамилия» (Last Name) и «Имя» (First Name), в область рядов — поле «Дата исполнения по месяцам» (Shipped Date By Month). Следите, как будет меняться область диаграммы.
- Перенесите поле «СуммаПродаж» (Sale Amount) в область данных — и диаграмма готова. Нажмите кнопку Добавить легенду (Show Legend), чтобы отобразить легенду, после чего вы получите диаграмму, представленную на рис. 8.52.
- Можно еще ввести надписи у осей диаграммы. Щелкните по надписи Название оси (Axis Title) под осью X. Выведите на экран окно Свойства (Properties) и раскройте вкладку Формат (Format). Введите в поле Заголовок (Caption): Сотрудники. Аналогично введите надпись Объем продаж для оси Y.
Рис. 8.52. Сводная диаграмма
Рис. 8.53. Сводная таблица «Продажи по сотрудникам и странам»
Замечание
Каи уже говорилось выше, одновременно со сводной диаграммой создается и сводная — таблица.
- Щелкните по стрелке на кнопке Вид (View) и переключитесь в режим сводной таблицы. Вы увидите сводную таблицу, показанную на рис. 8.53.
В данной лабораторной работе рассмотрим использование рисунков и диаграмм в СУБД Access.
Рисунки
В режиме конструктора форм СУБД Access имеется возможность использования графических элементов Линия и Прямоугольник. Данные элементы позволяют акцентировать внимание на определенных частях формы.
В режиме конструктора имеется возможность вставки рисунков двумя способами: Свободная рамка объекта и Присоединенная рамка объекта. Используя первый способ, можно вставить рисунок, который будет одинаково отображаться для всех записей. Это может быть, например, логотип компании. При помощи второго способа размещают рисунки, которые связаны с конкретными записями, например, база данных содержит информацию по сотрудникам и этот элемент позволяет выводить фотографию конкретного сотрудника при изменении записей.
Задание
- Поместите окно ввода в форме “Заказ с полем со списком” на выпуклый прямоугольник. Для этого выберите инструмент Прямоугольник и разместите его на необходимую область формы. При этом прямоугольник может перекрыть элементы формы. Далее сделайте прямоугольник прозрачным, выбрав Свойства — Тип фона — Прозрачный или выбрать пункт На задний план в пункте меню Формат. Затем выберите Свойство Оформление / Приподнятое. Отмечу также, что прямоугольник залить цветом, используя Свойство / Цвет фона.
- Добавьте логотип на одну из форм. Логотип создайте самостоятельно, например, в графическом редакторе Paint.
Мастер диаграмм
Удобным механизмом анализа и представления данных являются диаграммы. Распишу процесс построения диаграммы распределения по категориям цены товаров для таблицы ТОВАР.
- Создаем запрос “Категории и цены товаров” по таблицам ТОВАР и КАТЕГОРИЯ ТОВАРА, содержащий поля Значение и Цена, отсортированные по полю Значение.
- Используя созданный запрос, создаем форму “Диаграмма: Количество товаров по категориям”. Для этого на Ленте Создание в разделе Формы выберем Пустая форма и откроем ее в конструкторе, затем в Элементах управления найдем пиктограмму Вставить диаграмму нажмем на нее и выберем место на форме куда хотим ее вставить и автоматически откроется окно Создание диаграммы, выберем таблицу и запрос. В нашем случае это будет запрос Категории и цены товаров. Выберем поле Значение. В качестве формы диаграммы выберем Объемная круговая. Теперь введем заголовок диаграммы: Число товаров каждой категории и кнопкой Готово запустим построение диаграммы. Получим требуемую диаграмму.
- На полученной диаграмме есть названия категорий, но нет численных значений. Вызовем программу Microsoft Graph, которая собственно и создала нашу диаграмму. Для этого необходимо перейти в режим Конструктора и вызвать программу двойным щелчком по светлому полю на диаграмме. В верхней строке меню теперь представлены пункты меню приложения Microsoft Graph. Выберем пункты Диаграмма / Параметры диаграммы… / Подписи данных / Значение. Нажмем кнопку ОК. Теперь цифры числа записей данной категории появятся. При необходимости их можно переместить в нужные места. Если хотим, можем вывести проценты.
Задание
- Создайте диаграмму Количество товаров по категориям (создание описано выше).
- Для того же запроса “Категории и цены товаров” создайте столбчатую диаграмму значений средней цены товаров по категориям. В качестве полей диаграммы возьмем оба поля запроса. Выберем тип диаграммы Гистограмма. Далее в процессе диалога с мастером дважды щелкнем левой кнопкой мыши по кнопке Сумма_Цена. Откроется окно выбора функции, выберем Avg. Название кнопки теперь поменяется на Среднее_Цена Дадим диаграмме название Средняя цена товаров по категориям.
- Создать для этого же запроса вертикальную столбцовую диаграмму (Гистограмму) “Число товаров”, показывающую количество товаров по категориям.
- Замените на предыдущей круговой диаграмме вывод чисел на вывод процентов.
- Создайте круговую диаграмму “Категория покупателей – количество товаров”, показывающую количество товаров, приобретенных каждым покупателем.
Лабораторная работа Access
Краткая теория вопроса
Информационная система (ИС) — программно-аппаратный комплекс, предназначенный для хранения и обработки информации о какой-либо предметной области.
Процесс создания ИС делится на ряд этапов. Обычно выделяют следующие этапы создания ИС:
- формирование требований к системе (анализ),
- проектирование,
- реализация,
- тестирование,
- ввод в действие,
- эксплуатация и сопровождение.
Важнейшим компонентом любой информационной системы является База данных (БД). База данных (Data Base) – структурированный, организованный набор данных, объединенный в соответствии с некоторой выбранной моделью и описывающий характеристики какой-либо физической или виртуальной системы.
Именно БД позволяет эксплуатировать ИС, выполнять ее текущее обслуживание, модифицировать и развивать её при модернизации предприятия (организации) или изменении информационных потоков, законодательства и форм отчетности предприятия (организации).
Согласно современной методологии, процесс создания ИС представляет собой процесс построения и последовательного преобразования ряда согласованных моделей на всех этапах жизненного цикла (ЖЦ) ИС. На каждом этапе ЖЦ создаются модели: организации, требований к ИС, проекта ИС, требований к приложениям и т. д.
Проектирование ИС охватывает три основные области:
- проектирование объектов данных (создание моделей данных), которые будут реализованы в базе данных;
- проектирование программ, экранных форм, отчетов, которые будут обеспечивать выполнение запросов к данным;
- учет конкретной среды или технологии, а именно: топологии сети, конфигурации аппаратных средств, используемой архитектуры (файл-сервер или клиент-сервер), параллельной обработки, распределенной обработки данных и т. п.
Модель – искусственный объект,представляющий собой отображение (образ) системы и её компонентов.
Модель данных (Data Model) – это графическое или текстовое представление анализа, который выявляет данные, необходимые организации с целью достижения ее миссии, функций, целей, стратегий, для управления и оценки деятельности организации. Модель данных выявляет сущности, домены (атрибуты) и связи с другими данными, а также предоставляет концептуальное представление данных и связи между данными.
Цель создания модели данных состоит в обеспечении разработчика ИС концептуальной схемой базы данных в форме одной модели или нескольких локальных моделей, которые относительно легко могут быть интегрированы в любую базу данных.
При создании моделей данных используется метод семантического моделирования. Семантическое моделирование основывается на значении структурных компонентов или характеристик данных, что способствует правильности их интерпретации (понимания, разъяснения). В качестве инструмента семантического моделирования используются различные варианты диаграмм сущность-связь (ER — Entity-Relationship) — ERD.
Существуют различные варианты отображения ERD, но все варианты диаграмм сущность-связь исходят из одной идеи — рисунок всегда нагляднее текстового описания. ER -диаграммы используют графическое изображение сущностей предметной области, их свойств (атрибутов), и взаимосвязей между сущностями.
Базовые понятия ERD
Сущность (таблица, отношение) — это представление набора реальных или абстрактных объектов (людей, вещей, мест, событий, идей, комбинаций и т. д.), которые можно выделить в одну группу, потому что они имеют одинаковые характеристики и могут принимать участие в похожих связях. Каждая сущность должна иметь наименование, выраженное существительным в единственном числе. Каждая сущность в модели изображается в виде прямоугольника с наименованием.
Можно сказать, что Сущности представляют собой множество реальных или абстрактных вещей (людей, объектов, событий, идей и т. д.), которые имеют общие атрибуты или характеристики.
Экземпляр сущности (запись, кортеж)- это конкретный представитель данной сущности.
Атрибут сущности (поле, домен) — это именованная характеристика, являющаяся некоторым свойством сущности.
Связь — это некоторая ассоциация между двумя сущностями. Одна сущность может быть связана с другой сущностью или сама с собою. Связи позволяют по одной сущности находить другие сущности, связанные с ней.
Каждая связь может иметь один из следующих типов связи:
Один-к-одному, многое-ко-многим, один-ко-многим.
Связь типа один-к-одному означает, что один экземпляр первой сущности (левой) связан с одним экземпляром второй сущности (правой). Связь один-к-одному чаще всего свидетельствует о том, что на самом деле мы имеем всего одну сущность, неправильно разделенную на две.
Связь типа многое-ко-многим означает, что каждый экземпляр первой сущности может быть связан с несколькими экземплярами второй сущности, и каждый экземпляр второй сущности может быть связан с несколькими экземплярами первой сущности. Тип связи много-ко-многим является временным типом связи, допустимым на ранних этапах разработки модели. В дальнейшем этот тип связи должен быть заменен двумя связями типа один-ко-многим путем создания промежуточной сущности.
Связь типа один-ко-многим означает, что один экземпляр первой сущности (левой) связан с несколькими экземплярами второй сущности (правой). Это наиболее часто используемый тип связи. Левая сущность (со стороны «один») называется родительской, правая (со стороны «много») — дочерней.
При разработке ER-моделей необходимо обследовать предметную область (организацию, предприятие) и выявить:
1) Сущности, о которых хранятся данные в организации (предприятии), например, люди, места, идеи, события и т.д., (будут представлены в виде блоков);
2) Связи между этими сущностями (будут представлены в виде линий, соединяющих эти блоки);
3) Свойства этих сущностей (будут представлены в виде имен атрибутов в этих блоках).
Задача: разработать информационную систему «Контингент студентов института».
Необходимо: изучить предметную область (образовательное учреждение) и процессы, происходящие в ней.
Для этого обследуем объект: знакомимся с нормативной документацией, опрашиваем работников института, изучаем существующий документооборот института, анализируем ситуацию и т.п.
В результате обследования определяем цель и задачи системы и формулируем постановку задачи.
Краткая постановка задачи: главная задача системы – сбор и обработка информации об основных участниках учебного процесса: студентах и преподавателях, формирование необходимых печатных форм (документов), используемых преподавателями в период зачётной недели и экзаменационной сессии, генерация сводных отчётов по результатам сессии для работников деканатов, института. При разработке системы следует учитывать, что она основывается на документации, поступающей из приёмной комиссии, деканатов и других подразделений института. Информация об успеваемости студентов должна накапливаться и храниться в течение всего периода обучения. В системе должен использоваться справочник специальностей и дисциплин (предметов), изучаемых студентами.
Таким образом, проектируемая система должна выполнять следующие действия:
- Хранить информацию о студентах и их успеваемости.
- На факультетах по определённой специальности печатать экзаменационные ведомости и другие документы.
Выделим все существительные в этих предложениях — это предполагаемые сущности и проанализируем их:
- Студент — явная сущность.
- Успеваемость — явная сущность.
- ? Факультет — нужно выяснить один или несколько факультетов в институте? Если несколько, то это — предполагаемая новая сущность.
- ? Специальность — нужно выяснить одна или несколько специальностей на факультете? Если несколько, то это — ещё одна сущность.
- Предмет — предполагаемая сущность.
На первоначальном этапе моделирования данных информационной системы явно выделены две основные сущности: Студент и Успеваемость.
Критерием успеваемости является наличие отметки о сдачи экзаменов.
Сразу возникает очевидная связь между сущностями — «студент сдаёт несколько экзаменов » и «экзамены сдаются каждым студентом». Явная связь Один-ко-многим. Первый вариант диаграммы выглядит так:
Мы знаем, что студенты учатся на факультетах, на определённой специальности и сдают экзамены по дисциплинам (предметам). Анализ предметной области показал, что студенты учатся на нескольких факультетах института по нескольким специальностях и сдают экзамены по определённому перечню предметов.
Исходя из этого, мы добавляем в ER-модель ещё несколько сущностей. В результате она будет выглядеть так:
На следующей стадии проектирования модели вносим атрибуты сущностей в диаграмму (предполагаем, что атрибуты выявлены на стадии обследования объекта и при анализе аналогов существующих систем) и получаем окончательный вариант ER— диаграммы:
Отметим, что предложенные этапы моделирования являются условными и нацелены на формирование общих представлений о процессе моделирования.
Разработанный выше пример ER-диаграммы является примером концептуальной диаграммы, не учитывающей особенности конкретной СУБД. На основе данной концептуальной диаграммы можно построить физическую диаграмму, которая будут учитывать такие особенности СУБД, как допустимые типы, наименования полей и таблиц, ограничения целостности и т.п.
Для преобразования концептуальной модели в физическую необходимо знать, что:
Каждая сущность в ER-диаграмме представляет собой таблицу базы данных.
Каждый атрибут становится колонкой (полем) соответствующей таблицы.
В некоторых таблицах необходимо вставить новые атрибуты (поля), которых не было в концептуальной модели — это ключевые атрибуты родительских таблиц, перемещённых в дочерние таблицы для того, чтобы обеспечить связь между таблицами посредством внешних ключей.
Выводы:
Семантическое моделирование данных основывается на технологии определения значения данных через их взаимосвязи с другими данными.
В качестве инструмента семантического моделирования используются различные варианты (нотации) диаграмм сущность-связь — (Entity-Relationship). Нотация — система условных обозначений, принятая в какой-либо области знаний или деятельности.
ER- диаграммы позволяют использовать наглядные графические обозначения для моделирования сущностей и их взаимосвязей. Основное достоинство метода состоит в том, модель строится методом последовательного уточнения и дополнения первоначальных диаграмм.
После создания концептуальной модели данных переходим к созданию физической модели средствами конкретной СУБД, а именно СУБД ACCESS. Для этого переходим к выполнению Практического задания №2
Приглашайте друзей на мой сайт
Подготовка
к генерации базы данных физического
уровня начинается с создания пустой БД
в среде той СУБД, куда планируется
генерировать ER-диаграмму.
Для этого надо запустить СУБД Access,
выполнить команду на создание новой
БД, присвоить ей имя и сохранить (рис.
28).
Рис.
28. Пустая БД с именем test_db
в СУБД Access
Затем
открываем ER-диаграмму
в среде ERwin
и с помощью списка выбора в стандартной
панели инструментов производим
переключение между логической и
физической моделью (рис.29). При переключении,
если физической модели еще не существует,
она будет создана автоматически. Теперь
надо выбрать СУБД, в которой будем
производить генерацию БД физического
уровня.
Для
этого следует выполнить команду DATABASE
/ Choose
database,
в появившемся диалоговом окне (рис. 30)
выбрать интересующую СУБД Access
и щелкнуть по кнопке <ОК>.
Рис.
29. Физическая модель БД в ERwin
Для установления соединения БД изERwincцелевой
СУБДAccessнеобходимо
выполнить командуDATABASE/Database
connection. В появившемся
диалоговом окне (рис.31) необходимо
указать путь к БД в СУБДAccess,
вписать имяadminи
нажать кнопкуConnect.
Для генерации БД физического уровня
в среде СУБДAccessнеобходимо
выполнить командуTOOLS
/ Forward Engineering
/ Schema Generation.В результате получаем диалог генерации
схемы БД (рис. 32), который имеет 3 закладки:
Рис.
30. Диалог выбора СУБД (сервера)
Рис.
31. Диалог присоединения к СУБД Access
Options.Служит для
задания опций генерации объектов базы
данных – триггеров, таблиц, представлений,
колонок, индексов и т.д. Для задания
опций генерации какого-либо объекта
следует выбрать объект в левом списке
закладки, после чего включить
соответствующую опцию в правом списке.
Рис.
32. Диалог генерации схемы БД
Во вкладке Summary
отображаются все опции, заданные во
вкладкеOptions. Список
опций вSummary можно
редактировать так же, как и вOptions.
Comment позволяет
внести комментарий для каждого набора
опций. Каждый набор опций может быть
именован (окноOptionSet,
кнопкиNew,RenameиDelete) и использован
многократно.
‘
CREATE
TABLE
“prodavec“
Set
ERwinTableDef
= ERwinDatabase.CreateTableDef(“prodavec”)
Set
ERwinField = ERwinTableDef.CreateField(“IDprod”, DB_LONG)
ERwinTableDef.Fields.Append
ERwinField
Set
ERwinField = ERwinTableDef.CreateField(“fio”, DB_TEXT, 20)
ERwinTableDef.Fields.Append
ERwinField
Set
ERwinField = ERwinTableDef.CreateField(“vozrast”, DB_TEXT,
20)
ERwinTableDef.Fields.Append
ERwinField
Set
ERwinField = ERwinTableDef.CreateField(“adress”, DB_TEXT,
20)
‘
CREATE
TABLE “tovar”
Set
ERwinTableDef = ERwinDatabase.CreateTableDef(“tovar”)
Set
ERwinField = ERwinTableDef.CreateField(“IDtov”, DB_LONG)
ERwinTableDef.Fields.Append
ERwinField
Set
ERwinField = ERwinTableDef.CreateField(“naimenovanie”,
DB_LONG)
ERwinTableDef.Fields.Append
ERwinField
Set
ERwinField = ERwinTableDef.CreateField(“cena”, DB_LONG)
ERwinTableDef.Fields.Append
ERwinField
Set
ERwinField = ERwinTableDef.CreateField(“proizvoditel”,
DB_TEXT, 20)
Рис.
33. Программа генерации таблиц БД
(SQL-скрипты)
Кнопка
Preview
вызывает диалог Schema
Generation
Preview,
в котором отображается SQL-скрипт,
создаваемый ERwin
для генерации системного каталога СУБД
(рис. 33).
Кнопка Printдиалога
предназначена для вывода на печать
создаваемогоERwinSQL-скрипта.
Кнопка Reportсохраняет
тот же скрипт вERS- илиSQL-текстовом файле. Эти
команды можно в дальнейшем редактировать
любым текстовым редактором и выполнять
при помощи соответствующей утилиты
сервера.
Рис. 34. ДиалогGenerateDatabaseSchema
Нажатие на кнопку Generateприведет к запуску процесса генерации
схемы. Возникает диалог связи с базой
данных, устанавливается сеанс связи с
сервером-базы данных (СУБДAccess),
и начинает выполнятьсяSQL-скрипт.
При этом возникает диалогGenerate
Database Schema(рис. 34).
По умолчанию в диалоге Generate
Database Schemaвключена опцияStop
If Failure.
Это означает, что при первой же ошибке
выполнение скрипта прекращается. Щелкнув
по кнопкеContinue, можно
продолжить выполнение. КнопкаAbortпрерывает выполнение. При выключенной
опцииStop If
Failureскрипт будет
выполняться, несмотря на встречающиеся
ошибки.
Для выполнения обратного проектирования
следует выбрать пункт меню Tools/Reverse
Engineer.
После
выполнения скриптов (рис. 33) в среде СУБД
Access
создается БД физического уровня (рис.
36).
Рис. 36. Структура БД физического уровня
в СУБД Access
Таким образом, на основе физической
модели ERwinможно сгенерировать
системный каталог СУБД или соответствующийSQL-скрипт. Этот процесс
называется прямым проектированием
(ForwardEngineering).
Тем самым достигается масштабируемость
– создав одну логическую модель данных,
можно сгенерировать физические модели
под любую поддерживаемуюERwinСУБД. С другой стороны,ERwinспособен по содержимому системного
каталога илиSQL-скрипту
воссоздать физическую и логическую
модель данных (ReverseEngineering).
На основе полученной логической модели
данных можно сгенерировать физическую
модель для другой СУБД и затем сгенерировать
ее системный каталог.
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]
- #
- #
- #
- #
- #
- #
- #
- #
- #
- #
- #
NovaInfo 76, с.322-327, скачать PDF
Опубликовано 27 декабря 2017
Раздел: Педагогические науки
Просмотров за месяц: 315
Аннотация
В данной работе рассмотрено создание ER-диаграммы на примере детского магазина.
Ключевые слова
ER-ДИАГРАММА, БАЗЫ ДАННЫХ, ПРОЕКТИРОВАНИЕ
Текст научной работы
Информационная модель предметной области представляет собой описание предметной области, выполненной без ориентации на программное и аппаратное обеспечение, используемые в будущем. Содержит исходную информацию о предметной области. Шаг создания инфологической модели называется инфологическим проектированием.
Целью инфологического моделирования является создание точного и полного отображения реального мира, используемого в будущем в качестве источника информации для построения базы данных.
Комплекс задач этого этапа состоит в выявлении общих информационных объектов и связей между ними. Результаты инфологического проектирования могут быть выражены в виде инфологической или концептуальной модели, которая представляет структуру данных. Для построения концептуальной модели используется метод моделирования «Сущность — связь» или ER-диаграмма.
При разработке стандартной схемы организации был определен следующий персонал, который включает: директора, администраторов, продавцов-консультантов по продажам, уборщиц, водителей. При организации работы магазина важным фактором является мобильная, квалифицированная работа сотрудников, способных организовать процесс обслуживания клиентов как можно быстрее и качественней.
Работа продавца-консультанта — это процесс, который можно разделить на следующие этапы:
- поиск нужного товара;
- формирование списка товаров;
- добавление информации о покупателях.
Информационные процессы этапов представлены в виде таблицы (Таблица 1.) .
Этап |
Информационные процессы |
1. поиск нужного товара |
поиск товара на складе посредством побуквенного ввода названия товара, фирмы изготовителя или цене в поле поиска; |
2. формирование списка товаров |
вывод выбранных товаров в отдельную таблицу; |
3. оформление документов клиента |
сохранение информации в базу данных; |
4. оформление продажи |
выбор количества продаваемого товара; |
После изучения предметной области и анализа структуры системы были определены объекты. Список сущностей и связей представлены в таблицах 2 и 3.
Название |
Ключ сущности |
Атрибуты сущности |
Детский магазин |
Код_магазина |
Название Адрес Телефон Почта ФамилияИО_владельца Адреса_магазинов Город Страна |
Сотрудники |
Код_сотрудника |
Должность ФамилияИО_сотрудника Паспортные данные Дата_рождения Пол Образование Телефон Дата_устройства Город Почта Код_магазина |
Поставщики |
Код_поставщика |
Адрес Телефон Страна Почта Категория_товара Фирма_товара Дата_поставки Количество |
Покупатели |
Код_покупателя |
ФамилияИО_покупателя Паспортные_данные Город Телефон Адрес Почта Постоянный_клиент |
Заказы |
Код_заказа |
ФамилияИО_заказчика Название_товара Количество Дата заказа Стоимость_заказа Код_доставки |
Товары |
Код_товара |
Артикул Категория Название Размер Материал В_наличии(шт) Заказано/ожидается Изображение Цена(шт) Количество Код_поставщика Код_типа Код_магазина |
№ |
Связь |
1 |
Поставщики ПОСТАВЛЮТ Товары |
2 |
Товары СОСТОЯТ Типы |
3 |
Товары НАХОДЯТСЯ Магазин |
4 |
Магазин РАБОТАЮТ Сотрудники |
5 |
Сотрудники ОФОРМЛЯЮТ Заказы |
6 |
Заказы ДЕЛАЮТ Клиенты |
Исходя из имеющихся данных, становится возможным построить ER-диаграмму, необходимую для дальнейшего проектирования информационной системы (рис.1).
Следующим шагом проектирования является создание логической структуры реляционной базы данных. Каждый информационный объект модели данных отображается с соответствующей реляционной таблицей. Структура реляционной таблицы определяется требуемым составом соответствующего информационного объекта, где каждый столбец (поле) соответствует одному из реквизитов объекта. Ключевые реквизиты объекта образуют уникальный ключ реляционной таблицы. Для каждого столбца вы указываете формат и размер данных. Строки (записи) таблицы соответствуют экземплярам объекта и генерируются при загрузке таблицы.
Связи между объектами модели данных реализуются теми же реквизитами — ключи связи в соответствующих таблицах. Ключом соединения всегда является уникальный ключ главной таблицы. Ключ в подчиненной таблице — это либо часть уникального ключа в нем, либо поле, которое не является частью первичного ключа. Ключ связи в подчиненной таблице называется внешним ключом. В Access можно создать схему данных, визуально представляющую логическую структуру базы данных. Определение отношений «один ко многим» в этой схеме должно соответствовать построенной модели данных. Появление схемы данных практически совпадает с графическим представлением информационно-логической модели. В таблицах 4 и 5 показаны структуры объектов “Товары” и «Сотрудники». Аналогично можно получить и другие таблицы базы данных.
Ключевое поле |
Название поля |
Тип поля |
Ключ |
Код_товара |
Счетчик |
Артикул |
Текстовый |
|
Категория |
Текстовый |
|
Название |
Текстовый |
|
Размер |
Числовой |
|
Материал |
Текстовый |
|
В наличии(шт) |
Текстовый |
|
Заказано/Ожидается |
Текстовый |
|
Изображение |
Поле объекта OLE |
|
Цена(шт) |
Денежный |
|
Количество |
Числовой |
|
Код поставщика |
Числовой |
|
Код типа |
Числовой |
|
Код магазина |
Числовой |
Ключевое поле |
Название поля |
Тип поля |
Ключ |
Код_сотрудника |
Счетчик |
Должность |
Текстовый |
|
ФИО сотрудника |
Текстовый |
|
Паспортные данные |
Числовой |
|
Дата рождения |
Дата/время |
|
Пол |
Текстовый |
|
Образование |
Текстовый |
|
Телефон |
Числовой |
|
Фотография |
Поле объекта OLE |
|
Дата устройства |
Дата/время |
|
Город |
Текстовый |
|
Почта |
Текстовый |
|
Код магазина |
Числовой |
Используя правила перевода ER-диаграмму на логическую схему можно завершающую схему — логическую схему данных (рис. 2)
Таким образом, в данной работе подробно рассмотрено получение ER-диаграммы и логической схемы на примеры детского магазина.
Читайте также
-
Концепция лингвориторического проектирования программы ДПО для работников сферы гостеприимства (китайский язык)
- Черняков Э.В.
- Ворожбитова А.А.
-
Проектирование и моделирования образовательного процесса в современной дошкольной организации
- Воробьева Е.С.
- Газизова Ф.С.
-
Многофункциональные здания
- Черепанова Н.Б.
-
Проблемы надежности деталей машин
- Покровский А.А.
-
Проектирование автоматизированного рабочего места диспетчера службы такси
- Хусаинова Г.Я.
Список литературы
- Айнуров К.И. Использование информационных технологий в обучении. – Магнитогорск.: МГПУ, 2014. – 85 с.
- Викторов С.У. Развитие информационных технологий.– Пермь: ЛНА, 2011. – 74 с.
- Хусаинов И.Г., Рахимова Р.А. Роль интерактивных технологий на уроках информатики в развитии этического воспитания учащихся // Современные проблемы науки и образования. – 2015. – № 3. – С. 488.
- Хусаинова Г.Я. Исследование температурных полей при стационарном течении аномальных жидкостей // Автоматизация. Современные технологии. 2016. № 7. С. 13-16.
Цитировать
Хусаинова, Г.Я. Методика построения ER-диаграммы для базы данных / Г.Я. Хусаинова. — Текст : электронный // NovaInfo, 2017. — № 76. — С. 322-327. — URL: https://novainfo.ru/article/14504 (дата обращения: 23.05.2023).
Поделиться
Страницы работы
Содержание работы
СТРУКТУРА БАЗЫ ДАННЫХ
ER-диаграмма
ER-диаграмма представляет собой модель «сущность-связь».
В данной БД выделяются 3 сущности: турагентство, заказ, покупатель (табл.1).
Вводя связи между сущностями, ER-диаграмму
системы можно представить в виде ER-диаграммы
Таблица 1
Сущность |
Набор атрибутов |
Турагенство |
– Код тура – Название тура – Страна – Отель – Дата вылета – Количество дней – Цена – Наличие |
Заказ |
– Код заказа – Название тура – Покупатель – Дата заказа – Количество |
Покупатель |
– Код покупателя – Телефон – Покупатель – Адрес – Фотография |
Рис. 7.ER Diagram (Microsoft Access)
Таблицы
База данных состоит из следующих таблиц:
«Турагентство», «Заказ», «Покупатель».
Рис.
8. Типы данных таблицы Турагентство
Рис.
9. Таблица Турагентство
Рис.
10. Типы данных таблицы Заказ
Рис.
11. Таблица Заказ
Рис.
12. Типы данных таблицы Покупатель
Рис.
13. Таблица Покупатель
Запросы, описание, формы, отчеты
Разработанные
запросы:
- “Простой” запрос
вывод
на экран полей: Покупатель, Телефон;
таблица:
Покупатель.
- Запрос общий из
многих таблиц
вывод на
экран полей из нескольких таблиц: Покупатель, Адрес, Дата Заказа, Название Тура,
Страна;
таблицы: Покупатель,
Заказ, турагентство
- Запрос на больше
или меньше
вывод на
экран полей: Дата Заказа, Покупатель и Количество;
таблицы: Покупатель,
Заказ.
На экран
выводятся только те строки, где параметр “Дата Заказа” <01.10.2009.
·
Запрос по текстовому значению
атрибута
вывод на экран полей: Название Тура, Покупатель, Дата
Заказа, Адрес, Телефон;
таблицы: Покупатель,
Заказ.
На экран выводятся только те
строки, где параметр “Название Тура” = ‘Свадебный’.
- Запрос like
вывод на экран полей: Покупатель, Дата Заказа,
Адрес;
таблицы: Покупатель,
Заказ.
На экран выводятся только те
строки, в которых параметр “фамилия” начинается с буквы “М”.
- “Параметрический” запрос
вывод на экран полей: Тур, Страна;
таблица: турагентство.
Спрашивает название страны и затем
выводит строки, содержащие её.
·
Запрос between
вывод на экран полей: Покупатель, Дата Заказа, Название Тура, Страна;
таблицы: Заказ,
турагентство.
На экран выводятся только те
строки, в которых параметр “Дата Заказа” не ниже 01.10.2009 года и не выше 10.10.2009
года.
·
“Параметрический” запрос с between
вывод на экран полей: Тур,
Количество Дней;
таблица: турагентство.
Спрашивает минимальное, а затем
максимальное количество дней и выводит все туры в заданном диапазоне.
·
“Вычисляемый” запрос
вывод на экран полей Покупатель, Количество, Цена, стоимость;
таблицы: турагентство, Заказ
Выводит на экран помимо прочих
столбцов один дополнительный (стоимость), в котором подсчитывается общая стоимость
за купленные туры.
- Группировка с
суммированием
вывод на экран полей: Покупатель, Sum-КоличествоКуплТуров;
таблица: Заказ.
Подсчитывает количество купленных туров
у каждого покупателя, не взирая на название тура.
·
Сортировка по числовому полю
вывод
на экран полей: Покупатель, Дата Заказа, Количество таблицы:
Заказ.
Выводит
на экран отсортированную по возрастанию по дате заказа сводную таблицу.
- IIF
запрос
вывод
на экран полей: Покупатель, Количество, Цена, ЦенаСоСкидкой;
таблицы:
турагентство, Заказ.
Выводит
на экран помимо прочих столбцов один дополнительный (ЦенаСоСкидкой), в котором “отпускная
цена” умножается на 0,9, если “количество купл туров” больше 2.
- Or
запрос
вывод на экран полей: Покупатель, Название
Тура, Страна, Отель;
таблицы: турагентство,
Заказ.
Выводит на экран выбранные столбцы туров
в Польшу и Англию.
·
Создать таблицу
CREATE TABLE тур (ID INT NOT NULL , Название CHAR(32) NOT
NULL, Цена INT NOT NULL,Наличие
INT NOT NULL, PRIMARY KEY(ID))
- Добавить столбец
ALTER TABLE тур
ADD КоличествоДней INT;
- Внести данные в таб-цу
INSERT
INTO тур
VALUES
(‘1’, ‘ТурПоЕгипту’, ‘10000’, ‘4’);
- Добавить данные из ст-ца из другой таблицы
INSERT
INTO тур
SELECT
TOP 10 турагентство.[КодТура] AS [КодТура], турагентство.[НазваниеТура] AS [НазваниеТура],
турагентство.Цена AS Цена, турагентство.Наличие AS Наличие
FROM турагентство;
- Обновить данные по условию
UPDATE тур
SET цена = 20000.
WHERE [КодТура]=1;
- Удалить данные по условию
DELETE *
FROM
видеосоздание
WHERE [КодТура]=1;
- Like
SELECT турагентство.[НазваниеТура],
турагентство.Цена, турагентство.Наличие
FROM турагентство
WHERE (((турагентство.[НазваниеТура])
Like ‘Т*’));
- count
SELECT
Заказ.[Покупатель], count(*) AS [ЧислоЗаказов]
FROM
Заказ
GROUP BY
Заказ.[Покупатель];
- and
SELECT турагентство.[НазваниеТура],
турагентство.Цена, турагентство.Наличие
FROM турагентство
WHERE (((турагентство.Цена)>=10000))
and (((турагентство.Наличие)>=2));
- group
SELECT
Заказ.[Покупатель], SUm(количество) AS сумма
FROM
Заказ
GROUP BY
Заказ.[Покупатель];
- having
SELECT Заказ.Покупатель,
Sum(Заказ.Количество) AS сумма
FROM
Заказ
GROUP BY
Заказ.Покупатель
HAVING
(((Sum(Заказ.Количество))>=50));
- >,<,=
Похожие материалы
- Null-значение. Целостность внешних ключей. Поддержание ссылочной целостности. Запросы на удаление. Функциональные зависимости. Нормализация
- SQL-инструкции для определения данных DDL и манипулирования данными DML. Обеспечение целостности данных
- Программирование в MS ACCESS
Информация о работе
Тип:
Отчеты по лабораторным работам