Информационные хранилища
КУРСОВАЯ РАБОТА
Информационные хранилища
Введение
информационный реляционный хранилище
Данная тема курсовой является актуальной, так как в наше время необходимы хранилища, которые будут хранить в себе значительное количество информации, обрабатывать ее и предоставлять пользователю в удобном варианте. Информационные хранилища позволяют собрать в едином месте всю информацию, которая может понадобиться управляющему при принятии решения. Источниками данных для информационного хранилища служат в первую очередь данные из разрозненных транзакционных и учетных информационных систем, основанных на различных реляционных СУБД, которые обслуживают повседневную бизнес-деятельность. Источниками необходимой информации могут быть также газеты, радио, телевидение, интернет и любые другие. При этом предполагается, что данные предварительно должны быть приведены к единым стандартам, очищены от противоречий, структурированы и обобщены с требуемым уровнем детализации. Информационные хранилища служат исключительно для обработки и анализа информации, поэтому проектируются они таким образом, чтобы время выполнения запросов было минимальным. Изучением информационных хранилищ занимались многие исследователи. Среди отечественных ученных эту тему затрагивали в своих работах: С.Я. Архипенкова, B.C. Белова, Д.В. Голубева, В.И. Грекула, Г.Н. Денищенко, Н. T. Коровкиной, О.Б. Максименко, Г.Н. Смирновой, Ю.Ф. Тельнова, В. Чадаева, И. Шеметовой. Большой вклад в развитии теории информационных хранилищ внесли зарубежные исследователи: Б. Девлин, У. Инмон, Р. Кимпбалл, М. Росс, Э. Спирли
Объектом данной курсовой работы создание базы данных салона красоты для целей обоснованного принятия решений и построения управленческой и обязательной отчетности. Предметом курсовой работы является автоматизация работы фирмы и ведения бизнеса при помощи СУБД Microsoft Access. Целью теоретической части курсовой работы является раскрытие предназначения информационных хранилищ. В ходе работы в теоретической части мы ставим перед собой такие задачи:
Изучение общих теоретических сведений об информационных хранилищах.
Анализ свойств и компонентов информационного хранилища.
Ознакомление с понятием интеграции данных.
Целью практической части курсовой работы является освоение методов проектирования баз данных в среде СУБД Microsoft Access и реализация проекта.
Задачи практической части курсовой работы:
Освоение основ работы с Microsoft Access.
Проектирование базы данных различными методами.
Реализация базы данных в Microsoft Access.
В этой работе используются такие методы как «сущность-связь» и метод нормальных форм. Для достижения наших целей использовалась литература следующих авторов: Т.С. Карповой, А.Д. Хомоненко, Э.В. Фуфаева, В.И. Швецова и других.
1. Общие теоретические сведения об информационных хранилищах
.1 Назначение информационного хранилища
Информационное хранилище (Data Warehousing) - это место хранения данных предприятия, предназначенное для упрощения принятия управленческих решений. Информационное хранилище включает в себя не только данные, но также инструменты, процедуры, обучение, персонал и другие ресурсы, облегчающие доступ к данным и делающие его более осмысленным для лиц, принимающих решения. Назначение информационного хранилища состоит в увеличении ценности информационных активов предприятия [15].Роль информационного хранилища заключается в том, чтобы хранить выдержки из рабочих данных и выдавать их пользователям в удобном формате. Это могут быть как выдержки из базы данных и файлов, так и отсканированные образы документов, записи, фотографии и другие данные. Информационные хранилища служат для хранения, комбинирования, агрегирования, преобразования и доставки данных пользователям с помощью средств анализа и принятия решений, таких как OLAP [10].Информационное хранилище считается новым этапом представления данных в рамках современных бизнес-процессов. Концепция информационных хранилищ предложена в 1990 году Уильямом Инмоном. По-иному информационное хранилище - есть предметно-ориентированный, интегрированный, неизменный, поддерживающий хронологию набор данных, предназначенный для поддержки принятия решений. В этом определении соединены две различные функции:
сбор, организация, подготовка данных для анализа в виде постоянно наращиваемой базы данных;
анализ, как элемент принятия решений.
Назначение информационного хранилища заключается в следующем:
интеграция данных в масштабе бизнес-процессов;
функционально-стоимостной анализ эффективности бизнес-процессов;
сложные аналитические запросы в разрезах: виды услуг, клиенты, регионы, технологии;
анализ данных в динамике и в сравнении с показателями отрасли. Основная цель информационного хранилища - сделать все значимые для управления бизнесом данные доступными в стандартизованной форме, пригодными для анализа и получения необходимых отчетов [7].
.2 Свойства информационного хранилища
Уильям Инмон дал классическое определение информационного хранилища в 1990 г. Он охарактеризовал его как специальным образом администрируемую базу данных, содержимое которой имеет следующие свойства:
Предметная ориентация
Интегрированность данных
Инвариантность во времени
Неразрушаемость - стабильность информации
Минимизация избыточности информации
Предметная ориентация
В отличие от БД в традиционных OLTP-системах, где данные подобраны в соответствии с конкретными приложениями, информация в DW ориентирована на задачи поддержки принятия решений. Для системы поддержки принятия решений требуются «исторические» данные - факты продаж за определенные интервалы времени. Хорошо спроектированные структуры данных DW отражают развитие всех направлений бизнеса компании во времени.
Поскольку в DW-технологии объекты данных выходят на первый план, то особые требования предъявляются к структурам БД, используемым для создания информационных хранилищ. Принципиально отличаются и структуры баз данных для OLTP- и DW-систем. Во втором случае в них помещается только та информация, которая может быть полезной для работы систем поддержки принятия решений (DSS).
Интегрированность данных
Данные в информационное хранилище поступают из различных источников, где они могут иметь разные имена, атрибуты, единицы измерения и способы кодировки. После загрузки в DW данные очищаются от индивидуальных признаков, т.е. как бы приводятся к общему знаменателю. С этого момента они представляются пользователю в виде единого информационного пространства.
Если в четырех разных приложениях пол клиента кодировался четырьмя различными способами, то в информационном хранилище будет использована единая для всех данных схема кодировки (например, f, m).
Инвариантность во времени
В OLTP-системах истинность данных гарантирована только в момент чтения, поскольку уже в следующее мгновение они могут измениться в результате очередной транзакции. Важным отличием DW от OLTP-систем является то, что данные в них сохраняют свою истинность в любой момент процесса чтения.
В OLTP-системах информация часто модифицируется как результат выполнения каких-либо транзакций. Временная инвариантность данных в DW достигается за счет введения полей с атрибутом «время» (день, неделя, месяц) в ключи таблиц. В результате записи в таблицах DW никогда не изменяются, представляя собой снимки данных, сделанные в определенные отрезки времени. В DW содержатся как бы моментальные снимки данных. Каждый элемент в своем ключе явно или косвенно хранит временной параметр, например день, месяц или год.
Неразрушаемость - стабильность информации
В OLTP-системах записи могут регулярно добавляться, удаляться и редактироваться. В DW-системах, как следует из требования временной инвариантности, однажды загруженные данные теоретически никогда не меняются. По отношению к ним возможны только две операции: начальная загрузка и чтение (доступ). Это и определяет специфику проектирования структуры базы данных для DW. Если при создании OLTP-систем разработчики должны учитывать такие моменты, как откаты транзакций после сбоя сервера, борьба с взаимными блокировками процессов (deadlocks), сохранение целостности данных, то для DW данные проблемы не столь актуальны - перед разработчиками стоят другие задачи, связанные, например, с обеспечением высокой скорости доступа к данным.
Минимизация избыточности информации
Поскольку информация в DW загружается из OLTP-систем, возникает вопрос, не ведет ли это к чрезмерной избыточности данных? Нет, утверждает Билл Инмон. На самом деле избыточность минимальна (около 1%!), что объясняется следующими причинами:
·при загрузке информации из OLTP-cистем в DW данные фильтруются. Многие из них вообще не попадают в DW, поскольку лишены смысла с точки зрения использования в системах поддержки принятия решений;
·информация в OLTP-системах носит, как правило, оперативный характер, и данные, потеряв актуальность, удаляются. В DW, напротив, хранится историческая информация, и с этой точки зрения перекрытие содержимого DW данными OLTP - систем оказывается весьма незначительным;
·в DW хранится некая итоговая информация, которая в базах данных OLTP-систем вообще отсутствует;
·во время загрузки в DW записи сортируются, очищаются от ненужной информации и приводят к единому формату. После такой обработки это уже совсем другие данные.
.3 Компоненты информационного хранилища
ПО промежуточного слоя
Обеспечивает сетевой доступ и доступ к базам данных. Сюда относятся сетевые и коммуникационные протоколы, драйверы, системы обмена сообщениями и пр.
Транзакционные БД и внешние источники информации
Базы данных OLTP-систем исторически предназначались для эффективной обработки структур данных в относительно небольшом числе четко определенных транзакций. Из-за ограниченной целевой направленности «учетных» систем применяемые в них структуры данных плохо подходят для систем поддержки принятия решений. Кроме того, возраст многих установленных OLTP-систем достигает 10 - 15 лет.
Уровень доступа к данным
Относящееся сюда ПО обеспечивает общение конечных пользователей с информационным хранилищем и загрузку требуемых данных из транзакционных систем. В настоящее время универсальным языком общения служит язык структурированных запросов (SQL).
Загрузка и предварительная обработка
Этот уровень включает в себя набор средств для загрузки данных из OLTP-систем и внешних источников. Выполняется, как правило, в сочетании с дополнительной обработкой: проверкой данных на чистоту, консолидацией, форматированием, фильтрацией и пр.
Информационное хранилище
Представляет собой ядро всей системы - один или несколько серверов БД.
Метаданные
Метаданные (репозиторий, «данные о данных»). Играют роль справочника, содержащего сведения об источниках первичных данных, алгоритмах обработки, которым исходные данные были подвергнуты, и т.д.
Уровень информационного доступа
Обеспечивает непосредственное общение пользователя с данным DW посредством стандартных систем манипулирования, анализа и предоставления данных типа MS Excel, MS Access, Lotus 1-2-3 и др.
Уровень управления (администрирования)
Отслеживает выполнение процедур, необходимых для обновления информационного хранилища или поддержания его состояния. Здесь программируются процедуры подкачки данных, перестройки индексов, выполнения итоговых (суммирующих) расчетов, репликации данных, построения отчетов, формирования сообщений пользователям, контроля целостности и др.
2. Проблемы, их решение и реализация информационных хранилищ
.1 Проблемы интеграции данных
Остановимся на некоторых проблемах реализации хранилища данных:
·Неоднородность программной среды
·Повышенные требования к безопасности данных
·Необходимость наличия многоуровневых справочников метаданных
·Потребность в эффективном хранении и обработке очень больших объемов информации
Неоднородность программной среды
Хранилище данных практически никогда не создается на пустом месте. Почти всегда конечное решение будет разнородным, т.е. в нем будут использоваться автономно разработанные программные средства. Прежде всего это касается формирования интегрированного согласованного набора данных, которые могут поступать из разнородных баз данных, электронных архивов, публичных и коммерческих электронных каталогов, справочников, статистических сборников. При построении хранилища данных приходится решать задачу построения единой, согласованно функционирующей информационной системы на основе неоднородных программных средств и решений. При выборе средств реализации хранилища данных приходится учитывать множество факторов, включающих уровень совместимости различных программных компонентов, легкость их освоения и использования, эффективность функционирования и т.д.
Распределенный характер организации
В концепции хранилища данных предопределено то, что операционная аналитическая обработка может выполняться в любом узле сети независимо от места расположения основного хранилища. Хотя при аналитической обработке данные только читаются, и потребность в синхронизации отсутствует, для достижения эффективности необходимо поддерживать репликацию данных в разных узлах сети. (На самом деле, все не так просто. Одним из требований к хранилищам данных является то, чтобы свежая информация поступала в хранилище как можно быстрее. Т.е. потенциально любая модификация оперативной БД может инициировать добавление данных к хранилищу данных, а тогда потребуется обновить и все реплики, для чего синхронизация все-таки нужна.)
Повышение требований к безопасности данных
Собранная вместе согласованная информация об истории развития корпорации, ее успехах и неудачах, о взаимоотношениях с поставщиками и заказчиками, об истории и состоянии рынка дает возможность анализа прошлой и текущей деятельности корпорации и построения прогнозов для будущего. Эта информация настолько ценна для корпорации, что нельзя допустить возможности ее утечки (на самом деле, если хранилище данных одной корпорации попадет в руки аналитиков другой корпорации, то все аналитические прогнозы первой корпорации сразу станут неверными). В системах, основанных на хранилищах данных, оказывается недостаточной защита данных в стиле языка SQL, которую обеспечивают обычные коммерческие СУБД (этот уровень защиты соответствует классу C2 в соответствии с классификацией Оранжевой Книги Министерства обороны США). Для обеспечения должного уровня защиты доступ к данным должен контролироваться не только на уровне таблиц и их столбцов, но и на уровне отдельных строк (это уже соответствует классу B1 Оранжевой Книги). Приходится также решать вопросы аутентификации пользователей, защиты данных при их перемещении в хранилище данных из оперативных баз данных и внешних источников, защиты данных при их передаче по сети.
Необходимость наличия многоуровневых справочников метаданных
Если роль метаданных (обычно содержащихся в таблицах-каталогах) в оперативных информационных системах достаточно ограничена, то для OLAP-систем наличие развитых метаданных и средств их предоставления конечным пользователям является одним из основных условий успешной реализации. Например, прежде, чем менеджер корпорации задаст системе свой вопрос, он должен понять, какая информация имеется, насколько она актуальна, можно ли ей доверять, сколько времени может занять формирование ответа и т.д. Для пользователя OLAP-системы требуются метаданные, по крайней мере, следующих типов:
(1) Описания структур данных, их взаимосвязей.
(2) Информация о хранимых на хранилище данных и поддерживаемых им агрегатах данных.
(3) Информация об источниках данных и о степени их достоверности. Одна и та же информация могла попасть в хранилище данных из разных источников. Пользователь должен иметь возможность узнать, какой источник был выбран основным, и каким образом производились согласование и очистка данных.
(4) Информация о периодичности обновлений данных. Желательно знать не только то, какому моменту времени соответствуют интересующие его данные, но и когда они в следующий раз будут обновлены.
(5) Информация о владельцах данных. Пользователю OLAP-системы может оказаться полезной информация о наличии в системе данных, к которым он не имеет доступа, о владельцах этих данных и о действиях, которые он должен предпринять, чтобы получить доступ к данным.
(6) Статистические оценки времени выполнения запросов. До выполнения запроса полезно иметь хотя бы приблизительную оценку времени, которое потребуется для получения ответа, и объема этого ответа.
Потребность в эффективном хранении и обработке очень больших объемов информации
Уже сейчас известны примеры хранилищ данных, содержащих терабайты информации. По данным консалтинговой компании Meta Group, около половины корпораций, использующих или планирующих использовать хранилища данных, предполагает довести их объем до сотен гигабайт. Проблемой таких больших хранилищ является то, что накладные расходы на внешнюю память возрастают нелинейно при возрастании объема хранилища. Исследования, проведенные на основе тестового набора TPC-D, показали, что для баз данных объемом в 100 гигабайт потребуется внешняя память объемом в 4.87 раза большая, чем нужно собственно для полезных данных. При дальнейшем росте баз данных этот коэффициент увеличивается.
.2 Реализация хранилищ и витрин данных
Варианты реализации хранилищ данных
·Виртуальное хранилище данных
·Витрины данных
·Глобальное хранилище данных
·Многоуровневая архитектура хранилища данных
Виртуальное хранилище данных
В его основе - репозиторий метаданных, которые описывают источники информации (БД транзакционных систем, внешние файлы и др.), SQL-запросы для их считывания и процедуры обработки и предоставления информации. Непосредственный доступ к последним обеспечивает ПО промежуточного слоя. В этом случае избыточность данных нулевая. Конечные пользователи фактически работают с транзакционными системами напрямую со всеми вытекающими отсюда плюсами (доступ к «живым» данным в реальном времени) и минусами (интенсивный сетевой трафик, снижение производительности OLTP-систем и реальная угроза их работоспособности вследствие неудачных действий пользователей-аналитиков).
Витрина данных
Витрина данных (Data Mart) по своему исходному определению - это набор тематически связанных баз данных, которые содержат информацию, относящуюся к отдельным аспектам деятельности корпорации. По сути дела, витрина данных - это облегченный вариант хранилища данных, содержащий только тематически объединенные данные. Целевая база данных максимально приближена к конечному пользователю и может содержать тематически ориентированные агрегатные данные. Витрина данных, естественно, существенно меньше по объему, чем корпоративное хранилище данных, и для его реализации не требуется особо мощная вычислительная техника.
Глобальное хранилище данных
В последнее время все более популярной становится идея совместить концепции хранилища и витрины данных в одной реализации и использовать хранилище данных в качестве единственного источника интегрированных данных для всех витрин данных. Тогда естественной становится такая трехуровневая архитектура системы:
На первом уровне реализуется корпоративное хранилище данных на основе одной из развитых современных реляционных СУБД. Это хранилище интегрированных в основном детализированных данных. Реляционные СУБД обеспечивают эффективное хранение и управление данными очень большого объема, но не слишком хорошо соответствуют потребностям OLAP-систем, в частности, в связи с требованием многомерного представления данных.
На втором уровне поддерживаются витрины данных на основе многомерной системы управления базами данных (примером такой системы является Oracle Express Server). Такие СУБД почти идеально подходят для целей разработки OLAP-систем, но пока не позволяют хранить сверхбольшие объемы данных (предельный размер многомерной базы данных составляет 10-40 Гбайт). В данном случае это и не требуется, поскольку речь идет о витринах данных. Заметим, что витрина данных не обязательно должна быть полностью сформирована. Она может содержать ссылки на хранилище данных и добирать оттуда информацию по мере поступления запросов. Конечно, это несколько увеличивает время отклика, но зато снимает проблему ограниченного объема многомерной базы данных.
Наконец, на третьем уровне находятся клиентские рабочие места конечных пользователей, на которых устанавливаются средства оперативного анализа данных.
.3 Подходы и имеющиеся решения
Компания IBM
Решение компании IBM называется A Data Warehouse Plus. Целью компании является обеспечение интегрированного набора программных продуктов и сервисов, основанных на единой архитектуре. Основой хранилищ данных является семейство СУБД DB2. Преимуществом IBM является то, что данные, которые нужно извлечь из оперативной базы данных и поместить в хранилище данных, находятся в системах IBM. Поэтому естественная тесная интеграция программных продуктов.
Предлагаются три решения для хранилищ данных:
(1) Изолированная витрина данных. Предназначен для решения отдельных задач вне связи с общим хранилищем корпорации.
(2) Зависимая витрина данных. Аналогичен изолированной витрине данных, но источники данных находятся под централизованным контролем.
(3) Глобальное хранилище данных. Корпоративное хранилище данных, которое полностью централизовано контролируется и управляется. Глобальное хранилище данных может храниться централизовано или состоять из нескольких распределенных в сети рынков данных.
Oracle
Решение компании Oracle в области хранилищ данных основывается на двух факторах: широкий ассортимент продуктов самой компании и деятельность партнеров в рамках программы Warehouse Technology Initiative. Возможности Oracle в области хранилищ данных базируются на следующих составляющих:
·наличие реляционной СУБД Oracle 7, которая постоянно совершенствуется для лучшего удовлетворения потребностей хранилищ данных;
·существование набора готовых приложений, обеспечивающих возможности разработки хранилища данных;
·высокий технологический потенциал компании в области анализа данных;
·доступность ряда продуктов, производимых другими компаниями.
Hewlett Packard
Работы, связанные с хранилищами данных, выполняются в рамках программы OpenWarehouse. Выполнение этой программы должно обеспечить возможность построения хранилищ данных на основе мощных компьютеров HP, аппаратуры других производителей и программных компонентов. Основой подхода HP являются Unix-платформы и программный продукт Intelligent Warehouse, который предназначен для управления хранилищами данных. Основа построения хранилищ данных, предлагаемая HP, оставляет свободу выбора реляционной СУБД, средств реинжиниринга и т.д.
NCR
Решение компании направлено на решение проблем корпораций, у которых одинаково сильны потребности и в системах поддержки принятия решений, и в системах оперативной аналитической обработки данных. Предлагаемая архитектура называется Enterprise Information Factory и основывается на опыте использования системы управления базами данных Teradata и связанных с ней методах параллельной обработки.
Informix Software
Стратегия компании в отношение хранилищ данных направлена на расширение рынка для ее продуктаOn-Line Dinamic Parallel Server. Предлагаемая архитектура хранилища данных базируется на четырех технологиях: реляционные базы данных, программном обеспечении для управления хранилищем данных, средствах доступа к данным и платформе открытых систем. Три последние компонента разрабатываются партнерами компании. После выхода Универсального Сервера, основанного на объектно-реляционном подходе, можно ожидать, что и он будет использоваться для построения хранилищ данных.
SAS Institute
Компания считает себя поставщиком полного решения для организации хранилища данных. Подход основан на следующем:
·обеспечение доступа к данным с возможностью их извлечения из самых разнообразных хранилищ данных (и реляционных, и нереляционных);
·преобразование данных и манипулирование ими с использованием 4GL;
·наличие сервера многомерных баз данных;
·большой набор методов и средств для аналитической обработки и статистического анализа.
Sybase
Стратегия компании в области хранилищ данных основывается на разработанной ей архитектуреWarehouse WORKS. В основе подхода находится реляционная СУБД Sybase System 11, средство для подключения и доступа к базам данных OmniCONNECT и средство разработки приложений PowerBuilder. Компания продолжает совершенствовать свою СУБД для лучшего удовлетворения потребностей хранилищ данных (например, введена побитная индексация).
Software AG
Деятельность компании в области хранилищ данных происходит в рамках программы Open Data Warehouse Initiative. Программа базируется на основных продуктах компании ADABAS и Natural 4GL, собственных и приобретенных средствах извлечения и анализа данных, средстве управления хранилищем данных SourcePoint. SourcePoint позволяет автоматизировать процесс извлечения и пересылки данных, а также их загрузки в хранилище данных.
3. Проектирование реляционной базы данных «Салон красоты»
.1 Анализ предметной области
Основной целью данной курсовой работы является проектирование базы данных «Салон красоты», которая поддерживает структурированную обработку данных о клиентах, сотрудниках, услугах и т.д.
База данных «Салон красоты» проста в применении и может быть использована даже человеком, который владеет только основами знаний по информатике.
Человек, который работает с базой данных «Салон красоты», может вести списки клиентов, сотрудников, а также имеет возможность прослеживать оплату по выполненным услугам, выводить информацию по клиентам и сотрудникам, делать отчеты и т.д.
Задачи, которые необходимо решить с использованием БД «Салон красоты»:
)сокращение избыточности хранимых данных;
)обработка данных (вывод нужной информации в отчетах, запросах и т.д.);
)на основе данных можно отслеживать информацию об оказанных услугах и услугах, которые запланированы на будущее.
Требования к базе данных:
1)целостность базы данных;
)многократное использование данных;
)быстрый поиск и получение информации по запросам пользователей;
)простота обновления данных;
)адекватность отображения данных.
.2 Проектирование базы данных «Салон красоты» методом нормальных форм
Проектирование базы данных является одним из этапов жизненного цикла информационной системы. Основной задачей, решаемой в процессе проектирования, является задача нормализации ее отношений.
Окончательная цель нормализации сводится к получению такого проекта базы данных, в котором каждый факт появляется лишь в одном месте, т.е. исключена избыточность информации.
Перечень атрибутов базы данных «Салон красоты» представлен в (приложение 1).
Одно из требований к отношениям заключается в том, чтобы все атрибуты отношения имели атомарные значения. В исходном отношении каждый атрибут кортежа также должен быть простым. Исходное отношение «Салон красоты» представлено в (приложение 2).
Нормализация отношения.
Метод нормальных форм является классическим методом проектирования реляционных баз данных. Этот метод основан на фундаментальном в теории реляционных баз данных понятии зависимости между атрибутами отношений.
Нормализация - процесс разбиения (декомпозиции) отношений с неудовлетворительными свойствами на новые отношения.
Первая нормальная форма. Отношение находится в первой нормальной форме, если все его атрибуты являются простыми (имеют единственное значение). Исходное отношение строится таким образом, чтобы оно находилось в 1НФ.
ID клиентаФамилияИмяОтчествоТелефонПостоянствоАдрес2КонстантиноваЕвгенияПетровна+79876547624даг. Новочебоксарск, ул. Восточная 32ID песетителяКлиентУслугаСотрудникДатаВремяУслуга оказана3ИльинамассажСоколова02.05.201416:00да
ID клиентаICQE-mailSkype4783323232angelina@mail.ru645ang
ID услугиНазваниеГруппаСебестоимостьЦенаСотрудникуОписание услуги3массажSPA-процедуры10010000,2
ID должностиНазваниеГруппа услугГрафик работы5SPA-специалистSPA-процедуры2/2
ID сотрудникаФамилияИмяОтчествоДолжностьАдресТелефон5АртакинаНинаВикторовнаМаникюршаг. Чебоксары, ул. 50 лет октября 40+79032584671
Для перевода отношения в 2НФ используется операция проекции, то есть разложения отношения на несколько отношений.
Так как в данном отношении нет составного ключа, то оно уже находится в 2НФ.
Третья нормальная форма.
Отношение находится в 3НФ, если:
) отношение находится в 2НФ,
) каждый неключевой атрибут нетранзитивно зависит от первичного ключа.
Или
) ни одно из неключевых полей не должно однозначно идентифицироваться значением другого неключевого поля (полей).
Так как в наших отношениях не имеется транзитивных зависимостей, значит, наше отношение уже находится в 3НФ.
Нормальная форма Бойса-Кодда.
R1. «Клиенты»
*ID клиентаФамилияИмяОтчествоТелефонПостоянствоАдрес. «Посещение»
*ID песетителяКлиентУслугаСотрудникДатаВремяУслуга оказана. «Контакты»
*ID клиентаICQE-mailSkype. «Услуги»
*ID услугиНазваниеГруппаСебестоимостьЦенаСотрудникуОписание услуги
R5. «Группы услуг»
*ID группыНазвание. «Должности»
*ID должностиНазваниеГруппа услугГрафик работы. «Сотрудники»
*ID сотрудникаФамилияИмяОтчествоДолжностьАдресТелефон
Построенные отношения R1, R2, R3, R4, R5, R6, R7 находятся в нормальной форме Бойса-Кодда, поскольку в них отсутствуют зависимости ключевых атрибутов от неключевых.
2.4 Проектирование базы данных «Салон красоты» в соответствии с методом «сущность-связь»
Метод проектирования «сущность-связь» или, как его еще называют, ER - метод является универсальным методом проектирования баз данных.
Правила формирования отношений основываются на учете следующего:
степени связи между сущностями (1:1, 1:М, М:1, М:М);
класса принадлежности экземпляров сущностей (обязательный и необязательный).
Рассмотрим формулировки шести правил формирования отношений на основе диаграмм ER-типа.
Формирование отношений для связи 1:1
Правило 1. Если степень бинарной связи 1:1 и класс принадлежности обеих сущностей обязательный, то формируется одно отношение. Первичным ключом этого отношения может быть ключ любой из двух сущностей.
На рис. 1 приведены диаграмма ER-типа и отношение, сформированное по правилу 1 на ее основе.
Рис. 1 Формирование отношения по правилу 1
Правило 2. Если степень связи 1:1 и класс принадлежности одной сущности обязательный, а второй - необязательный, то под каждую из сущностей формируется по отношению с первичными ключами, являющимися ключами соответствующих сущностей. Далее к отношению, сущность которого имеет обязательный КП, добавляется в качестве атрибута ключ сущности с необязательным КП.
На рис. 2 приведены диаграмма ER-типа и отношения, сформированные по правилу 2 на ее основе.
Рис. 2 Формирование отношения по правилу 2
Правило 3. Если степень связи 1:1 и класс принадлежности обеих сущностей является необязательным, то необходимо использовать три отношения. Два отношения соответствуют связываемым сущностям, ключи которых являются первичными в этих отношениях. Третье отношение является связным между первыми двумя, поэтому его ключ объединяет ключевые атрибуты связываемых отношений.
На рис. 3 приведены диаграмма ER-типа и отношения, сформированные по правилу 3 на ее основе.
Рис. 3 Формирование отношения по правилу 3
Формирование отношений для связи 1:М
Правило 4. Если степень связи между сущностями 1:М (или М:1) и класс принадлежности М-связной сущности обязательный, то достаточно формирование двух отношений (по одному на каждую из сущностей). При этом первичными ключами этих отношений являются ключи их сущностей. Кроме того, ключ 1-связной сущности добавляется как атрибут (внешний ключ) в отношение, соответствующее М-связной сущности.
На рис. 4 приведены диаграмма ER-типа и отношения, сформированные по правилу 4 на ее основе.
Рис. 4 Формирование отношения по правилу 4
Правило 5. Если степень связи 1:М (М:1) и класс принадлежности М-связной сущности является необязательным, то необходимо формирование трех отношений (рис. 5). Два отношения соответствуют связываемым сущностям, ключи которых являются первичными в этих отношениях. Третье отношение является связным между первыми двумя (его ключ объединяет ключевые атрибуты связываемых отношений).
Рис. 5 Формирование отношения по правилу 5
Формирование отношений для связи М:М
Правило 6. Если степень связи М:М, то независимо от класса принадлежности сущностей формируются три отношения. Два отношения соответствуют связываемым сущностям и их ключи являются первичными ключами этих отношений. Третье отношение является связным между первыми двумя, а его ключ объединяет ключевые атрибуты связываемых отношений.
На рис. 6 приведены диаграмма ER-типа и отношения, сформированные по правилу 6.
Рис. 6 Формирование отношения по правилу 6
В базе данных «Радиостанция» имеются следующие сущности:
·Клиенты (Ключ - ID клиента,…)
·Группы услуг (Ключ - ID группы,…)
·Сотрудники (Ключ - ID сотрудника,…)
·Должности (Ключ - ID должности,…)
·Посещения (Ключ - ID посетителя,…)
·Контакты (Ключ - ID клиента,…)
Схема диаграммы ER-типа (рис. 7) построена с учетом всех сущностей и связей между ними с целью повышения наглядности и удобства проектирования.
Рис. 7 Схема ER-диаграммы «Салон красоты»
После добавления неключевых атрибутов в схему, отношения примут следующий вид:
·Клиенты (*ID клиента, Фамилия, Имя, Отчество, Телефон, Постоянство, Адрес)
·Посещения (*ID посетителя, Клиент, Услуга, Сотрудник, Дата, Время, Услуга оказана)
·Услуги (*ID услуги, Название, Группа, Себестоимость, Цена, Сотрудники, Описание услуги)
·Группы услуг (*ID группы, Название)
·Сотрудники (*ID сотрудника, Фамилия, Имя, Отчество, Должность, Адрес, Телефон)
·Должности (*ID должности, Название, Группы услуг, График работы)
·Контакты (*ID клиента, ICQ, E-mail, Skype).
Полученные в результате проектирования базы данных «Салон красоты» методом «сущность-связь» соответствует нормальной форме Бойса-Кодда.
Таким образом, в данной главе было проведено проектирование базы данных «Салон красоты» методом нормальных форм и методом «сущность-связь». Получившиеся в результате проектирования этими методами отношения и схемы данных совпали.
4. Реализации базы данных «Салон красоты» в среде MS Access
.1 Таблицы и запросы
Состав таблиц базы данных «Салон Красоты» с ключами и связями (Рис. 8).
Рис. 8 Схема базы данных «Салон красоты»
Выборка информации осуществляется при помощи запросов, которые представлены в этом разделе.
)Запрос на выборку. Выводит ID посетителя, Услугу, если не стоит отметки о оказании услуги (Рис. 9).
Рис. 9 Запрос на выборку
2)Запрос на создание таблицы. Создается новая таблица с информацией о выполненных услугах и с отметкой о выполнении (Рис. 10)
Рис. 10 Запрос на создание таблицы
)Перекрёстный запрос. Выводит Ф.И.О. клиента, оказанные услуги и стоимость (Рис. 11).
Рис. 11 Перекрёстный запрос
)Запрос на удаление с параметром. Удаляет из таблицы контакты информацию о конкретном клиенте (Рис. 12).
Рис. 12 Запрос на удаление
)Запрос с параметром. При запуске запроса на экране появляется окно, в которое нужно ввести ID клиента. Тогда при вводе, например, числа 1, выводится вся информация по клиенту, которой принадлежит этот код (Рис. 14).
Рис. 14 Запрос с параметром
6)Итоговый запрос. Выводит информацию о том, сколько раз каждый клиент посетил салон (Рис. 15).
Рис. 15 Итоговый запрос
В данном разделе был приведен состав таблиц БД «Салон красоты» и реализованы все виды запросов.
4.2 Отчеты и формы
В данном разделе будет рассмотрена реализация форм и отчетов в базы данных «Салон красоты».
В базе данных «Салон красоты» реализована удобная кнопочная форма, которая является окном, в котором будет работать пользователь. При открытии базы данных появляется окно кнопочной формы, которое предоставляет все возможности работы с БД. Данная форма дает возможность доступа ко всем разделам базы данных, содержащие все необходимые виды информации в виде запросов, отчетов и форм (рис. 16).
Рис. 16 Форма «Главное окно»
Информацию о клиентах можно посмотреть в форме «Клиенты» (Рис. 17).
Рис. 16 Форма «Клиенты»
Информацию об услугах можно посмотреть в форме «Услуги» (Рис. 17)
Рис. 17 Форма «Услуги»
Примером отчетов в проектируемой базе данных является отчет обо всех услугах в салоне красоты (приложение 3).
4.3 Макросы и модули
Модули представляют наборы описаний, инструкций и процедур, сохраненных под общим именем для организации программ на языке Microsoft Visual Basic. Существуют два основных типа модулей: модули класса и стандартные модули.
Модули форм и модули отчетов являются модулями класса, связанными с определенной формой или отчетом. Они часто содержат процедуры обработки событий, запускаемые в ответ на событие в форме или отчете.
В стандартных модулях содержатся общие процедуры, не связанные ни с каким объектом, а также часто используемые процедуры, которые могут быть запущены из любого окна базы данных.
Примером модуля является модуль на открытие окна калькулятора (Рис. 18).
Рис. 18 Модуль на нажатие кнопки и открытие окна калькулятора
Макрос - это набор команд, которые можно применить, нажав всего лишь одну клавишу. С помощью макроса можно автоматизировать любое действие, которое выполняется в используемом приложении, и даже выполнять действия, о возможности выполнения которых вы даже не догадывались.
Примером макросов являются следующие макросы:
·Макрос открытие запроса (Рис. 19)
Рис. 19 Макрос «ОткрытьЗапрос»
·Макрос на открытие одной формы и закрытие другой (Рис. 20)
Рис. 20 Макрос «ОткрытьФорму» и «Закрыть»
В данной главе рассмотрена реализация форм, отчетов, макросов и модулей в проектируемой базе данных.
Таким образом, реализована база данных «Салон красоты» в СУБД MS Access. Она содержит таблицы, в которых хранится информация об услугах, сотрудниках, клиентах и т.д. Необходимы запросы, формы, отчеты, макросы и модули успешно реализованы.
Заключение
В ходе выполнения курсовой работы был выполнен анализ предметной области. На основании анализа были составлены локальные представления и ER - диаграмма. Анализ предметной области позволил также, при определении требований к операционной обстановке, определить объем работы информационной системы.
Полученная база данных может быть применена во многих организациях. Использование СУБД может значительно поднять имидж организации, клиентам не придется часами сидеть и ждать, когда менеджер найдет в ворохе бумаг необходимый бланк и т.д. Применять полученную базу данных рационально в больших организациях.
В основе любых технологических потрясений лежит простой финансовый вопрос. В основе нынешней ситуации в развитии распределенных систем также лежит экономическое обоснование - стоимость передачи данных по сети становится меньше стоимости вычислений на клиентской машине и эта тенденция имеет устойчивый характер. Взрывной рост Internet, который многие связывают с «демократическими свободами» или развитием новой технологии имеет в своей основе все тоже простое экономическое обоснование - эта технология экономически выгодна. Отсюда проистекают и те изменения в мире технологий свидетелями которых мы являемся: стремительный рост пропускной способности, присутствие в сети большинства корпораций, электронная коммерция и банки. На основе этих технологий выросли новые направления бизнеса, а распространенность Internet растет темпами невиданными в отрасли (быстрее телефонии и телевидения). И пока это будет происходить актуальность многопользовательских БД не иссякнет, её можно будет развивать в соответствии с нуждами пользователей.
Список использованной литературы
1.Вельмисов А.П. Методы и средства построения информационных хранилищ при автоматизированном проектировании: автореферат дисс… к. ю. н. Ульяновск, 2009.
.Голицына, О.Л. Базы данных: учеб. пособие / О.Л. Голицына, Н.В. Максимов. - М.: Инфра-М, 2009 (гриф МО РФ);
.Гущин О., Промзелева Т. Опыт внедрения в ОАО РПКБ электронного хранилища технической документации и его взаимодействие в структуре предприятия на базе системы Lotsia PDM PLUS. // http://www.lplm.ru/index.php? option=com_content&task=view&id=70&Itemid=27;
.Диго С.М. Базы данных: проектирование и использование, М.: Финансы и статистика, 2005;
.Дейт К.Дж. Введение в системы баз данных 8-е изд. - М.: «Вильямс», 2006;
6.Илюшечкин В.М., Основы использования и проектирования баз данных: учеб. пособие: Высшее образование, 2010;
7.Калабухов Е.В. Курс лекций по дисциплине: «Базы данных, знаний и экспериментальные системы», Минск, 2008;
.Кузнецов С.Д. Основы современных баз данных // Центр информационных технологий URL: http://citforum.ru/database/osbd/contents.shtml;
.Михеева Е. Информационные технологии в профессиональной деятельности. М., 2009;
.Пирогов В.Ю., Информационные системы и базы данных: организация и проектирование: БХВ-Петербург <http://www.my-shop.ru/shop/producer/4607.html>, 2009;
.Стулов А. Особенности построения информационных хранилищ // Открытые системы. №4. 2008;
.Фуфаев Э.В., Фуфаев Д.Э. Системы управления распределёнными БД // Учебное пособие URL: http://www.downloadpfree.narod.ru/#bookmark69
.Хомоненко А.Д., Цыганков В.М., Мальцев М.Г. Базы данных, Корона Прин, 2004;
.Цветкова А.В. Информатика и информационные технологии. Лекции. М., 2009.
.Швецов B.И. Базы данных, 2008.