Выдержка из текста работы
При создании БД и БнД выделяют следующие этапы концептуального (информационно-логического), логического (даталогического) и физического проектирования.
Этап1. Построение концептуальной модели предметной области.
В рамках этого этапа исследуется предметная область — часть реального мира, для которого создается база данных. Изучаются информационные потребности пользователей, выявляются информационные объекты и связи между ними. Исходя из полученной информации строится концептуальная модель предметной области, независимая от модели данных и программных средств (включая СУБД).
Этап 2. Логическое проектирование — преобразование созданной концептуальной модели в концептуальную схему, реализуемую конкретной СУБД. На этом этапе на основе концептуальной модели разрабатывается структура базы данных, соответствующая выбранной для ее создания СУБД. Для реляционной базы данных информация разбивается на отношения (таблицы); для каждого отношения (таблицы) определяются атрибуты (поля), первичные ключи; отношения приводятся к нормализованному виду; идентифицируются связи между отношениями.
Этап3. Физическое проектирование базы данных.
На этом этапе решаются проблемы физического размещения базы данных во внешней памяти и организации доступа к ней. Физическое проектирование базы данных реализуется администратором банка данных при конфигурировании и настройке системы. От специалистов, принимавших участие в проектировании базы данных на предыдущих этапах, этот процесс может быть полностью скрыт. Учитывая, что процесс физического проектирования базы данных является узко специализированным, в дальнейшем он рассматриваться не будет.
В2. Построение концептуальной модели предметной области.
Концептуальное проектирование базы данных. Процесс создания модели используемой на предприятии информации, не зависящей от любых физических аспектов ее представления.
Первый этап процесса проектирования базы данных называется концептуальным проектированием базы данных. Он заключается в создании концептуальной модели данных для анализируемой части предприятия. Эта модель данных создается на основе информации, записанной в спецификациях требований пользователей. Концептуальное проектирование базы данных абсолютно не зависит от таких подробностей ее реализации, как тип выбранной целевой СУБД, набор создаваемых прикладных программ, используемые языки программирования, тип выбранной вычислительной платформы, а также от любых других особенностей физической реализации.
При разработке концептуальная модель данных постоянно подвергается тестированию и проверке на соответствие требованиям пользователей. Созданная концептуальная модель данных предприятия является источником информации для этапа логического проектирования базы данных.
В3. Логическое проектирование базы данных.
Логическое проектирование заключается в определении числа и структуры таблиц, формировании запросов к БД, определении типов отчетных документов, разработке алгоритмов обработки информации, создании форм для ввода и редактирования данных.
Решение проблем проектирования на физическом уровне во многом зависит от используемой СУБД. Чаще всего пользователю предоставляется возможность настройки отдельных параметров, которая не составляет большой проблемы.
При проектировании баз данных и их эксплуатации к ним предъявляются следующие требования:
— адекватность отображения предметной области (полнота, целостность, непротиворечивость данных, актуальность);
— возможность взаимодействия пользователей разных категорий; обеспечение высокой эффективности доступа;
— дружественность интерфейса;
— обеспечение секретности и конфиденциальности;
— обеспечение взаимной независимости программ и данных;
— обеспечение надежности базы данных; защита данных от случайного и преднамеренного разрушения; возможность быстрого и полного восстановления данных в случае их разрушения.
В4. Нормализация отношений.
В реляционных базах данных отношения (таблицы) содержат как структурную, так и семантическую информацию. Структурная информация связана с объявлением отношений. Семантическая информация выражается множеством известных функциональных зависимостей между атрибутами отношений, имеющимися в схеме.
Таким образом, в отношениях (таблицах) практически всегда присутствуют функциональные зависимости. Для устранения нежелательных функциональных зависимостей между атрибутами (столбцами) Э.Kодд предложил использовать разработанный им процесс нормализации отношений. Это процедура декомпозиции (разложения), при которой данное множество отношений заменяется другим множеством отношений (при этом число их возрастает), являющихся проекциями первых. Другими словами, нормализация – это пошаговый обратимый процесс замены данной схемы отношений другой схемой, в которой отношения имеют более простую и регулярную структуру.
так, нормализация отношений – формальный аппарат ограничений на формирование таблиц, который позволяет устранить дублирование, обеспечивает непротиворечивость хранимых в базе данных, уменьшает трудозатраты на ведение БД.
Различают шесть нормальных форм:
1НФ — первую нормальную форму;
2) 2НФ — вторую нормальную форму;
3) 3НФ — третью нормальную форму;
4) НФБК — нормальную форму Бойса –Кодда;
5) 4НФ — четвертую нормальную форму;
6) 5НФ — пятую нормальную форму.
Каждая нормальная форма определяет ограничения на данные:
• 1НФ, 2НФ, 3НФ – ограничивают зависимость не первичных атрибутов от ключей;
• НФБК – ограничивает зависимость первичных атрибутов;
• 4НФ – формирует ограничения на виды многозначных зависимостей;
• 5НФ – вводит другие типы зависимостей: зависимости соединения.
Каждая нормальная форма более высокого уровня предполагает, что анализируемое отношение уже находится в нормальной форме на уровне ниже рассматриваемого. Для реляционных баз данных необходимо, чтобы все отношения базы данных обязательно находились в НФ, однако практически всегда стремятся довести уровень нормализации базы данных хотя бы до 3НФ.
Отношение называется нормализованным или приведенным к первой нормальной форме, если все его атрибуты простые, т.е. неделимы. В противном случае отношение считается ненормализованным и ему соответствует многоуровневая таблица (иерархия) в отличие от однородной табличной структуры нормализованного отношения.
В5. Автоматизированные технологии проектирования базы данных.
К концептуальной модели предъявляются следующие требования:
• адекватное отображение предметной области (язык для представления модели должен обладать достаточными выразительными возможностями для отображения явлений, имеющих место в предметной области, а сама модель должна содержать всю необходимую и достаточную информацию для дальнейшего проектирования системы);
• непротиворечивость (модель отражает взгляды и потребности всех пользователей системы, а также обычно является результатом работы многих специалистов, поэтому целостное описание ПО должно быть проверено на непротиворечивость);
• однозначная трактовка модели всеми ее пользователями (обеспечивается формализованностью языка и четким его пониманием всеми участниками процесса создания ИС);
легкость восприятия разными категориями пользователей (обеспечивается выбором соответствующего языка моделирования);
• конечность модели (несмотря на то, что реальный мир, отображаемый в КМ, является по своей природе бесконечным, инфологическая модель является конечной, что обеспечивается четким ограничением предметной области);
• легкость модификации (в концептуальную модель по разным причинам часто
приходится вводить новые объекты или модифицировать существующие; ИЛМ должна в связи с этим обладать свойством легкой расширяемости, обеспечивающим ввод новых данных без изменения раннее определенных. То же самое можно сказать и об удалении и корректировке данных);
• возможность композиции и декомпозиции модели (в связи с большой размерностью реальных инфологических моделей должна обеспечиваться возможность ее композиции и декомпозиции).
Желательно, чтобы язык спецификации концептуальной модели был одинаково применим как при ручном, так и при автоматизированном проектировании информационных систем. Последнее предъявляет к языку дополнительные требования, а именно, он должен:
• быть вычисляемым, то есть восприниматься и обрабатываться ЭВМ;
• использовать «дружелюбные» пользователю интерфейсы, в частности, графические;
• быть независимым от оборудования и других ресурсов, которые подвержены частым изменениям;
• использовать средства тестирования КМ, а также иметь аппарат для указания того,
что спецификация завершена и по ней может быть выполнена генерация структур баз данных.
При автоматизированном проектировании все изменения, внесенные в КМ, должны быть автоматически отражены в связанных с модифицируемым элементом компонентах банка данных.
Желательно, чтобы КМ строили специалисты, работающие в предметной области, для которой создается АИС, а не проектировщики систем машинной обработки данных. Если в силу определенных причин это невозможно обеспечить, то необходимо, чтобы первые могли хотя бы проверить сделанное другим специалистом описание, чтобы убедиться, что специфика предметной области воспринята и отображена правильно.
Задание 2 вариант 1
Расчёт повременной оплаты
1. Запустим Access 2016 и создадим таблицы:
Таблица 1. Справочник работников (структура таблицы – Табельный номер, Фамилия, Имя, Отчество, Разряд, Цех)
Таблица 2. Справочник тарифов (структура таблицы – Тариф (руб./час), Разряд)
Таблица3. Табель учета отработанного времени (структура таблицы – Табельный номер, отработанное время, номер месяца)
Таблица4. Ведомость начисления зарплаты (структура таблицы – Табельный номер, Фамилия, Имя, Отчество, Номер месяца, Цех, Тариф (руб./час), Начислено)
2. Создадим ведомость начисления зарплаты за один месяц с помощью запроса. Что бы открыть ведомость нужно вести месяц на пример введем цифру 5 в результате получим информацию начисление зарплату за май.
3. Создать формы «Табель» и «Сведенье о работниках»
4. Создадим отчеты «Платежная ведомость по цеху» и «Итоговые данные за два месяца»
«Платежная ведомость по цеху»
Итоговые данные за два месяца
Выводы
В данной работе было рассмотрено основы проектирования реляционных баз данных.
Проблема проектирования реляционной базы данных состоит в обоснованном принятии решений о том, из каких отношений должна состоять база данных и какие атрибуты должны быть у этих отношений.
При проектировании базы данных решаются две основных проблемы:
1. Каким образом отобразить объекты предметной области в абстрактные объекты модели данных, чтобы это отображение не противоречило семантике предметной области и было по возможности лучшим (эффективным, удобным и т.д.)? Часто эту проблему называют проблемой логического проектирования баз данных.
2. Как обеспечить эффективность выполнения запросов к базе данных, т.е. каким образом, имея в виду особенности конкретной системы управления базами данных, расположить данные во внешней памяти, создание каких дополнительных структур (например, индексов) потребовать и т.д.? Эту проблему называют проблемой физического проектирования баз данных.
Список используемой литературы
1. Гарсиа-Молина Г. Системы баз данных. Полный курс : пер. с англ. / Г. Гарсиа-Молина, Дж. Ульман, Дж. Уидом. — М. : Вильямс, 2003.- 1088 с.
2. Дейт К. Дж. Введение в системы баз данных : пер. с англ. / К. Дж. Дейт. — 6-е изд. — М. : Вильямс, 2000. — 848 с.
3. Диго С. М. Базы данных: проектирование и использование : учебник / С. М. Диго. — М. : Финансы и статистика, 2005. — 592 с.
4. Карпова Т. С. Базы данных: модели, разработка, реализация : учебное пособие / Т. С. Карпова. — СПб. : Питер, 2001. — 304 с.
5. Кренке Д. Теория и практика построения баз данных. — 9-е изд. — СПб. : Питер, 2005. — 859 с.
6. Марков А. С. Базы данных. Введение в теорию и методологию : учебник / А. С. Марков, К. Ю. Лисовский. — М. : Финансы и статистика, 2004. — 512 с.
7. Мещеряков Е. В. Публикация баз данных в Интернете / Е. В. Мещеряков, А. Д. Хомоненко. — СПб. : БХВ-Петербург, 2001. — 560 с.
8. Риккарди Г. Системы баз данных. Теория и практика использования в Internet и среде Java : пер. с англ. / Г. Риккарди. — М. : Вильямс, 2001. — 480 с.
9. Роб П., Коронел К. Системы баз данных: проектирование, реализация и управление : пер. с англ. / К. Коронел, П. Роб. — 5-е изд., перераб. и доп. — СПб. : БХВ-Петербург, 2004. — 1040 с.
10. Ролланд Ф. Д. Основные концепции баз данных : пер. с англ. / Ф. Д. Ролланд. — М. : Вильямс, 2002. — 256 с.
11. Толковый словарь по вычислительным системам / под ред. В. Иллингоурта и др. : пер с англ. — М. : Машиностроение, 1990. — 560 с.
12. Харрингтон Д. Разработка баз данных : пер. с англ. / Д. Харрингтон. — М. : ДМК Пресс, 2005. — 272 с.
13. Хомоненко А. Д. Базы данных : учебник / А. Д. Хомоненко, В. М. Цыганков, М. Г. Мальцев. — СПб. : КОРОНА принт, 2002. — 672 с.