Элементы разработки информационных систем на примере предметной области "Отдел сантехники в магазине"
Жизненный цикл и критерии эффективности информационных систем. Компоненты реляционной модели данных. Переход от ER-модели к реляционной модели данных. Проектирование информационных систем на примере предметной области "Отдел сантехники в магазине".
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | курсовая работа |
| Язык | русский |
| Дата добавления | 18.01.2018 |
| Размер файла | 951,3 K |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ОБРАЗОВАНИЮ
Государственное образовательное учреждение высшего профессионального образования
Рубцовский институт (филиал) Алтайского Государственного Университета
Кафедра математики и прикладной информатики
КУРСОВАЯ РАБОТА
По дисциплине: Теория информационных систем
Тема: Элементы разработки ИС на примере предметной области «Отдел сантехники в магазине»
Реферат
- Объем отчета составил 38 страниц, количество иллюстраций - 10, количество таблиц - 4, количество использованных источников - 13.
- Перечень ключевых слов: предметная область, компьютерная техника, ИС, база данных (БД), магазин, продавец, товар, сущность, физическая модель данных, логическая модель данных.
- Целью данной работы является описание основной теории ИС и разработка БД для определенной предметной области. Основные задачи, которые должны быть решены в данной работе:
- - описать понятие «информационная система»;
- - разработать БД для предметной области «Отдел компьютерной техники в магазине».
- Методы, используемые в работе: анализ представленной информации и проектирование. Результатом работы стало создание БД для использования в отделах по продаже сантехники. Предположительно, БД, полученная в ходе написания работы, будет в дальнейшем развиваться: сущности будут расширяться, возможно, добавляться новые или удаляться старые сущности.
- В процессе проектирования описаны основные объекты данной предметной области. Спроектирована ER-модель в среде Erwin 4.0 и созданы отношения в Microsoft Access.
Содержание
информационный система реляционный данные
Введение
1. Информационные системы в общем виде
1.1 История развития информационных систем
1.2 Жизненный цикл ИС
1.3 Критерии оценки эффективности ИС
1.4 Классификация ИС и ЭИС
1.5 ER-модель и ее компоненты
1.6 Реляционная модель данных и ее компоненты
1.7 Переход от ER-модели к реляционной модели данных
1.8 Нормализация отношений
1.9 CASE-средства автоматизированного проектирования системы
2. Проектирование ИС на примере предметной области
2.1 Предметная область «Отдел сантехники в магазине»
2.2 Моделирование данных предметной области
2.3 Исходные данные
2.4 SQL-запросы для БД
Заключение
Список использованных источников
Введение
Информационные системы (ИС) используются в настоящее время в различных сферах экономики. Прогресс в сфере экономики немыслим без применения современных информационных технологий (ИТ), которые представляют собой основу экономических информационных систем (ЭИС). Информационные системы в экономике имеют дело с организацией и эффективной обработкой больших массивов данных в компьютеризированных системах предприятий, обеспечивая информационную поддержку принятия решений менеджерами и другими работниками предприятия.
Применение ИС в бизнес - процессах (по уровню управления, по сфере применения, по характеру обрабатываемой информации, по уровню распределения потоков информации и управления) достаточно широко. ИС используются на различных предприятиях (пищевой промышленности, производственной), в коммерческих и некоммерческих организациях, в сельскохозяйственных отраслях и др. В последнее время появился широкий спектр специализированных ИС - экономические информационные системы (ЭИС), бухгалтерские информационные системы (БУИС), банковские информационные системы (БИС), информационные системы рынка ценных бумаг, маркетинговые ИС (МИС) и т.п.
Целью данной работы является исследование предметной области “учет платежей по уровням бюджета”, “учет плательщиков”и изучение их взаимосвязи.
Объект исследования - Бюджетная организация учитывающая, анализирующая и контролирующая платежи.
Предмет исследования - разработка ИС для оценки и мониторинга специально организованное, систематическое наблюдение за состоянием объектов, явлений, процессов с целью их оценки, контроля или прогноза состояния платежей в бюджет.
Для достижения цели курсового проекта необходимо решить следующие задачи:
- Учет поступлений в бюджет;
- Учёт плательщиков;
- Создание базы КБК (коды бюджетной классификации).
В данной работе рассмотрены: общая характеристика ИС, её классификация, пользователи, реляционная и ER-модели, переход от реляционной к ER-модели, нормализация, case-средства проектирования; В основной части - описание объектов и их связей, перенос данных из Erwina в Access, запросы и возможные подходы к обработке и анализу информации.
1. Информационные системы в общем виде
1.1 История развития информационных систем
Первые информационные системы появились в 50-хг. В эти годы они были предназначены для обработки счетов и расчета зарплаты, а реализовывались на электромеханических бухгалтерских счетных машинах. Это приводило к некоторому сокращению затрат и времени на подготовку бумажных документов. Такие системы называются системами обработки транзакций. К транзакциям относят следующие операции: выписка счетов, накладных, составление платежных ведомостей и другие операции бухгалтерского учета.
В 60-ег. средства вычислительной техники получили дальнейшее развитие: появляются операционные системы, дисковая технология, значительно улучшаются языки программирования. Появляются системы управленческих отчетов (СУО), ориентированные на менеджеров, принимающих решения.
В 70-ег. информационные системы продолжают активно развиваться. В это время появляются первые микропроцессоры, интерактивные дисплейные устройства, технология баз данных и дружественное по отношению к пользователю программное обеспечение (средства, позволяющие работать с программой, не изучая ее описания). Эти достижения создали условия для появления систем поддержки принятия решений (СППР). В отличие от систем управленческих отчетов, которые предоставляют информацию по заранее установленным формам отчетности, СППР предоставляют ее по мере возникновения необходимости.
Существуют 3 стадии принятия решения: информационная, проектная и стадия выбора. На информационной стадии исследуется среда, определяются события и условия, требующие принятия решений. На проектной стадии разрабатываются и оцениваются возможные направления деятельности (альтернативы). На стадии выбора обосновывают и отбирают определенную альтернативу, организуя слежение за ее реализацией. Важнейшей целью СППР является обеспечение технологией формирования информации, а также технологическая поддержка принятия решения в целом.
В 70-80-хг. в офисах начали применять разнообразные компьютерные и телекоммуникационные технологии, которые расширили область применения информационных систем. К таким технологиям относятся: текстовая обработка, настольное издательство, электронная почта и др. Интеграцию этих технологий в одном офисе называют офисной информационной системой. ИС начинают широко использоваться в качестве средства управленческого контроля, поддерживающего и ускоряющего процесс принятия решений.
1980-ег. характеризуются еще и тем, что информационные технологии начали претендовать на новую роль в организации: компании открыли для себя, что информационные системы являются стратегическим оружием. Информационные системы этого периода, предоставляя вовремя нужную информацию, помогают организации достичь успеха в своей деятельности, создавать новые товары и услуги, находить новые рынки сбыта, обеспечивать себе достойных партнеров, организовывать выпуск продукции по низкой цене и многое другое.
1.2 Жизненный цикл ИС
Одним из базовых понятий методологии проектирования ИС, является жизненный цикл (ЖЦ). В настоящее время существует ряд общих методологий разработки ИС. Главное в них - единая дисциплина работы на всех этапах жизненного цикла системы, учет критических задач и контроль их решения, применение развитых инструментальных средств поддержки процессов анализа, проектирования и реализации ИС.
Под термином жизненный цикл системы (System Life Cycle) понимается определенная эволюция, период времени и совокупность работ, меняющих состояние системы от появления замысла и начала ее разработки до окончания эксплуатации. Обычно разбивается на отдельные стадии -- анализ требований, проектирование, реализация (конструирование), верификация и эксплуатация. Стадии ЖЦ системы могут повторяться итерационным образом в связи с постепенным уточнением требований к системе и/или с необходимостью ее адаптации к тем изменениям, которые возникают в предметной области системы.
Понятие ЖЦ системы позволяет определить понятие жизненный цикл ИС (ЖЦ ИС) - это модель создания и использования (эволюция) ИС, отражающая ее различные состояния, начиная с момента возникновения необходимости в данном комплексе средств создания и обмена информацией, и заканчивая моментом ее полного выхода из употребления у пользователей.
ЖЦ ИС - это период времени и совокупность работ, от момента возникновения и обоснования необходимости создания до момента нецелесообразности дальнейшей ее эксплуатации, т.е. это совокупность взаимосвязанных процессов создания и последовательного изменения состояния ИС, меняющих состояние системы, от формирования исходных требований к ней до окончания эксплуатации и утилизации комплекса средств автоматизации ИС. Обычно разбивается на отдельные стадии - анализ требований, проектирование, реализация (конструирование), верификация и эксплуатация. Стадии жизненного цикла системы могут повторяться итерационным образом в связи с постепенным уточнением требований к системе и/или с необходимостью ее адаптации к тем изменениям, которые возникают в предметной области системы. Такой цикл проходят все технические, технологические и иные информационные системы и в каждом случае они должны быть экономически обоснованы и привязаны к конкретным условиям производства.
По стандарту ISO/IEC 12207 ЖЦ ИС базируется на трех группах процессов:
- основные процессы ЖЦ ИС: приобретение, поставка, разработка, эксплуатация, сопровождение. Разработка ИС состоит из трех этапов: анализ, проектирование и реализацию (программирование)
- вспомогательные процессы, обеспечивающие выполнение основных процессов: документирование, управление конфигурацией, обеспечение качества, верификация, аттестация, оценка, аудит, решение проблем
- организационные процессы: управление проектами, создание инфраструктуры проекта, определение, оценка и улучшение самого ЖЦ, обучение.
Модель ЖЦ ИС, как и модель ЖЦ изделия, разрабатывается на основе анализа создаваемого ПО для процесса проектирования нового изделия, и включает в себя набор этапов и связей между ними. Жизненный цикл ИС образуется в соответствии с принципом нисходящего проектирования и, как правило, носит итерационный характер: реализованные этапы, начиная с самых ранних, циклически повторяются в соответствии с изменениями требований и внешних условий, введением дополнительных ограничений и т.п., что приводит к изменениям в проектных решениях, выработанных на более ранних этапах.
Опыт создания и использования стандартных моделей ИС позволяет условно выделить следующие основные этапы жизненного цикла:
- стратегическое планирование;
- анализ требований и разработка спецификаций требований к ИС (в форме целей и стратегии), определение того, что должна делать система. Результатами анализа, в частности, являются функциональные модели, информационные модели и соответствующие им диаграммы;
- разработка методики проектирования (предварительного и детального) ИС в целом и ее компонент. Определение того, как система будет делать то, что она должна делать. Проектирование -- это спецификация подсистем, функциональных компонентов и способов их взаимодействия в системе;
- разработка - создание функциональных компонентов и подсистем по отдельности, соединение подсистем в единое целое. Разработка включает в себя все работы по созданию определенной продукции и ее компонент в соответствии с заданными требованиями. В разработку входит, например, оформление проектной и эксплуатационной документации, подготовка материалов, необходимых для проверки работоспособности и соответствующего качества, материалов, необходимых для организации обучения персонала и т.д.
- аттестационное тестирование на соответствие требованиям и отладка;
- внедрение - установка и ввод системы в действие;
- эксплуатация (использование) - работы по подготовке к внедрению компонентов ИС в эксплуатацию. К основным направлениям деятельности следует отнести:
- конфигурирование базы данных;
- конфигурирование рабочих мест пользователей;
- обеспечение эксплуатационной документацией;
- проведение обучения персонала;
- локализация проблем и устранение причин их возникновения;
- модификация ИС в рамках установленного регламента;
- подготовка предложений по совершенствованию, развитию и модернизации системы.
- сопровождение ИС - обеспечение штатного процесса эксплуатации системы на предприятии заказчика
Каждый процесс характеризуется определенными задачами и методами их решения, исходными данными, полученными на предыдущем этапе, и результатами. Результатами анализа, в частности, являются функциональные модели, информационные модели и соответствующие им диаграммы.
1.3 Критерии оценки эффективности ИС
Оценивая эффективность использования ИТ и ИС, необходимо рассматривать деятельность компаний с точки зрения удовлетворения информационных потребностей персонала предприятия. Пользователям требуется информационная поддержка определенных бизнес-процессов. Бизнес-процесс - ключевое понятие при оценке результатов эксплуатации ИС. Поддержка бизнес-процесса требует затрат, а выполнение формирует финансовый результат.
Важно разработать и согласовать критерии оценки эффективности функционирования ИС. Эти критерии для организаций, собирающих информацию для своих нужд или же для продажи, будут различны. В зависимости от целей организации возможны несколько различных вариантов критериев:
- Собираемая в рамках ИС информация предназначена для самой организации. При этом объективными критериями оценки функционирования информационной системы является количество и качество собранной информации, а также ее соответствие потребностям пользователей.
- Собираемая в рамках ИС информация предназначена для продажи. При этом критерием будет доход от продаж собранной информации и связанных с этим услуг.
- Сама ИС разрабатывается под конкретный заказ. При этом разработчик заинтересован в достаточно эффективном, с точки зрения заказчика, функционировании ИС и в своем доходе от этого.
Критерии оценки эффективности ИС:
- Удовлетворенность федеральных и региональных структур поддержки, ассоциации, союзов МП и самих МП собранной информацией. Это предполагается выяснять путем их периодических опросов;
- Количество и качество собранной информации должно быть достаточно для примерного анализа текущего состояния МП в каждом из регионов РФ. Также должны быть собраны ссылки на другие источники информации по МП в каждом из регионов РФ.
1.4 Классификация ИС и ЭИС
Как и к любому материальному объекту с ИС можно применить ту или иную систему классификации. При этом используются как иерархические с последовательной детализацией свойств ИС, так и фасетные варианты классификации, основанные на множестве независимых признаков.
Так, например, в зависимости от степени реализации мыслительных возможностей деятельности человека ИС целесообразно подразделить на следующие классы.
Низший класс - справочные (поисково-справочные) ИС - наиболее распространенный вариант, который в наименьшей степени использует достижения искусственного интеллекта.
Средний класс - интеллектуальные ИС, которые характеризуется использованием специализированных логических выводов, соответствующих тем предметным областям и задачам, на которые они настроены, т.е. можно говорить о том, что ИИС имитирует способ рассуждения конкретного специалиста-эксперта.
Высший класс - экспертные ИС, основанные на базах человеческих знаний, применяющие, обычно, проблемно-неориентированные (универсальные) процедуры получения выводов. Такие процедуры, оказываются весьма эффективными, но пригодными, к сожалению, только для ограниченного круга задач.
Дело в том, что в основе архитектуры экспертных систем лежит понятие о независимых правилах (продукциях), которые должны быть извлечены из опыта экспертов и вложены в систему. В противоположность этому в ИСС правила нельзя считать атомарными, так как в практической деятельности они взаимозависимы и взаимосвязаны. Следовательно, для ИИС базовым является представление о рассуждении специалиста как о внутреннем диалоге с атомарной процедурой «вопрос-ответ» на ограниченном естественном языке.
В связи с тем, что в этом случае решение аналогичной задачи известно, то и соответствующие рассуждения поддаются моделированию в ИСС. Поэтому использование подобных ИС наиболее эффективно в тех областях, где интеллектуальная деятельность человека носит достаточно рутинный характер, и многие компоненты управления уложены в привычные схемы.
В зависимости же от архитектуры ПО, а именно от варианта построения базы данных, ИС подразделяются, как правило, на [9]:
- автономные ИС;
- ИС в файл-серверной архитектуре;
- ИС в клиент-серверной архитектуре;
- ИС в многозвенной архитектуре;
- ИС в распределенной архитектуре.
Автономные ИС, функционируют, как правило, на одном, отдельном компьютере. Наряду с дешевизной и простотой эксплуатации достаточно привлекательной особенностью настольных информационных систем является так называемая персонализация рабочей среды, когда пользователь может выбрать для себя инструменты для работы (текстовый редактор, СУБД, электронную таблицу и др.), наиболее соответствующие его потребностям. Нередко электронные таблицы и настольные СУБД (dBase, FoxBase, Clipper, Paradox и др.), совмещают в себе собственно СУБД и средства разработки приложений, использующих базы данных.
ИС в файл-серверной архитектуре, когда компьютеры пользователей системы объединены в сеть, при этом на каждом из них запущены копии одной и той же программы, которые обращаются за данными к серверу. Особенность этой архитектуры в том, что все вычисления выполняются на клиентских местах, что требует наличия на них достаточно производительных ПК.
ИС в клиент-серверной архитектуре. Эта архитектура похожа на предыдущую, только сервер помимо простого обеспечения одновременного доступа к данным способен еще выполнять программы (обычно выполняются СУБД -- тогда сервер называется сервером баз данных), которые берут на себя определенный объем вычислений
Благодаря этому удается повысить общую надежность системы, так как сервер работает значительно более устойчиво, чем ПК, и снять лишнюю нагрузку с клиентских мест, на которых удается использовать дешевые компьютеры.
Частный (вырожденный) случай этого варианта - терминальный режим обработки данных с помощью одной общей ЭВМ
Характерной особенностью такой системы является полная "неинтеллектуальность" терминалов, используемых в качестве рабочих мест - их работой управляет так называемый хост-компьютер. При этом имеется возможность совместного использования различных ресурсов хост-компьютера, что существенно облегчает и удешевляет эксплуатацию такой системы.
К недостатку подобной архитектуры следует отнести полную зависимость пользователя от администратора хост-компьютера
ИС в многозвенной архитектуре. Недостаток предыдущей архитектуры в том, что резко возрастает нагрузка на сервер, а если он выходит из строя, то работа всей системы останавливается. Поэтому в некоторых случаях в систему добавляется так называемый сервер приложений, на котором выполняется вся вычислительная работа. Другой сервер баз данных обрабатывает запросы пользователей, на третьем может быть установлена специальная программа -- монитор транзакций, которая оптимизирует обработку транзакций и балансирует нагрузку на серверы. В большинстве практических случаев все серверы соединены последовательно -- позвенно, и выход из строя одного звена, если и не останавливает всю работу, то, по крайней мере, резко снижает производительность системы
ИС в распределенной архитектуре. Чтобы избежать недостатков рассмотренных архитектур, были придуманы специальные технологии, позволяющие создавать программу в виде набора компонентов, которые можно запускать на любых серверах, связанных в сеть. Основное преимущество подобного подхода в том, что при выходе из строя любого компьютера специальные программы-мониторы, которые следят за корректностью работы компонентов и позволяют им «переговариваться» между собой, сразу перезапуская временно пропавший компонент на другом компьютере. Доступ к возможностям любого компонента, предназначенного для общения с пользователем, осуществляется с произвольного клиентского места. При этом, так как все вычисления происходят на серверах, появляется возможность создавать сверхтонкие клиенты -- программы, только отображающие получаемую из сети информацию и требующие минимальных компьютерных ресурсов. Благодаря атому доступ к компонентной системе возможен не только с ПК, но и с небольших мобильных устройств.
Частный случай компонентного подхода -- доступ к серверным приложениям из броузеров через Интернет, когда обмен данными между клиентом и сервером осуществляется с использованием кроссплатформенных стандартов, а именно - протоколов низкого (TCP/IP) и высокого(HTTP) уровней
В связи с большим количеством функциональных особенностей для ЭИС может быть выделено множество различных классификационных признаков.
1. По функциональному признаку - выделяют системы обработки данных, информационно-поисковые системы и автоматизированные системы управления:
- СОД (система обработки данных) - предназначена для сбора, хранения, преобразования и представления информации с целью осведомления ЛПР в системе управления.
- ИПС (информационно-поисковые системы) - предназначены для хранения и выдачи ЛПР информации, главным образом текстового характера (документа).
- АСУ (автоматизированные системы управления) - системы, которые участвуют совместного специалистами в выработке и реализации управленческих решений.
2. По классу реализуемых технологических операций можно выделить следующие системы: системы с текстовыми редакторами, системы с табличными редакторами, СУБД, СУБЗ, системы с графикой, мультимедиа, гипертекстом.
3. По месту, в процессе управления предприятия: автоматизированное рабочее место специалиста, система руководителя, система внешнего контролера, интегрированные системы, объединяющие в себе часть или все из этих функций.
4. По характеру использования ресурсов: локальная и распределенные системы.
1.5 ER-модель и ее компоненты
Цель моделирования данных состоит в обеспечении разработчика концептуальной схемой базы данных в форме одной модели или нескольких локальных моделей, которые относительно легко могут быть отображены в любую систему баз данных.
Процесс создания моделей данных может проводиться ручным или автоматизированным методом. Автоматизированный метод проектирования осуществляется с помощью CASE-средств. Наиболее распространенным среди них на данный момент является ERwin.
ERwin - средство концептуального моделирования БД, использующее методологию IDEF1X. ERwin реализует проектирование схемы БД, генерацию ее описания на языке целевой СУБД (ORACLE, Informix, Ingres, Sybase, DB/2, Microsoft SQL Server, Progress и др.) и реинжиниринг существующей БД.
Основные понятия данной методологии:
Сущность (Entity) - реальный либо воображаемый объект, имеющий существенное значение для рассматриваемой предметной области, информация о котором подлежит хранению. Каждая сущность должна обладать уникальным идентификатором. Каждый экземпляр сущности должен однозначно идентифицироваться и отличаться от всех других экземпляров данного типа сущности. Каждая сущность должна обладать некоторыми свойствами:
- каждая сущность должна иметь уникальное имя, и к одному и тому же имени должна всегда применяться одна и та же интерпретация. Одна и та же интерпретация не может применяться к различным именам, если только они не являются псевдонимами;
- сущность обладает одним или несколькими атрибутами, которые либо принадлежат сущности, либо наследуются через связь;
- сущность обладает одним или несколькими атрибутами, которые однозначно идентифицируют каждый экземпляр сущности;
- каждая сущность может обладать любым количеством связей с другими сущностями модели.
Связь (Relationship) - поименованная ассоциация между двумя сущностями, значимая для рассматриваемой предметной области. Связь - это ассоциация между сущностями, при которой, как правило, каждый экземпляр одной сущности, называемой родительской сущностью, ассоциирован с произвольным (в том числе нулевым) количеством экземпляров второй сущности, называемой сущностью-потомком. А каждый экземпляр сущности-потомка ассоциирован в точности с одним экземпляром сущности-родителя. Таким образом, экземпляр сущности-потомка может существовать только при существовании сущности родителя.
Связи может даваться имя, выражаемое грамматическим оборотом глагола и помещаемое возле линии связи. Имя каждой связи между двумя данными сущностями должно быть уникальным, но имена связей в модели не обязаны быть уникальными. Имя связи всегда формируется с точки зрения родителя, так что предложение может быть образовано соединением имени сущности-родителя, имени связи, выражения степени и имени сущности-потомка.
Атрибут - любая характеристика сущности, значимая для рассматриваемой предметной области и предназначенная для квалификации, идентификации, классификации, количественной характеристики или выражения состояния сущности. Атрибут представляет тип характеристик или свойств, ассоциированных с множеством реальных или абстрактных объектов (людей, мест, событий, состояний, идей, пар предметов и т.д.). Экземпляр атрибута - это определенная характеристика отдельного элемента множества. Экземпляр атрибута определяется типом характеристики и ее значением, называемым значением атрибута. В ER-модели атрибуты ассоциируются с конкретными сущностями. Таким образом, экземпляр сущности должен обладать единственным определенным значением для ассоциированного атрибута. Атрибут может быть либо обязательным, либо необязательным. Обязательность означает, что атрибут не может принимать неопределенных значений (null values). Атрибут может быть либо описательным (т.е. обычным дескриптором сущности), либо входить в состав уникального идентификатора (первичного ключа).
Уникальный идентификатор - это атрибут или совокупность атрибутов и/или связей, предназначенная для уникальной идентификации каждого экземпляра данного типа сущности. В случае полной идентификации каждый экземпляр данного типа сущности полностью идентифицируется своими собственными ключевыми атрибутами, в противном случае в его идентификации участвуют также атрибуты другой сущности-родителя.
1.6 Реляционная модель данных и ее компоненты
Определение модели данных предусматривает указание множества допустимых информационных конструкций, множества допустимых операций над данными и множества ограничений для хранимых значений данных.
Модель данных, с одной стороны, представляет собой формальный аппарат для описания информационных потребностей пользователей, а с другой - большинство СУБД ориентируются на конкретную модель данных, и, таким образом, если информационные потребности удается точно выразить средствами одной из моделей данных, то соответствующая СУБД позволяет относительно быстро создать работоспособный фрагмент ЭИС.
Количество существенно различных моделей данных определяется наличием различных множеств информационных конструкций. С этой точки зрения принципиальными различиями обладают три модели данных - реляционная, сетевая и иерархическая.
Реляционная модель данных характеризуется следующими компонентами:
- информационной конструкцией - отношением с двухуровневой структурой;
- допустимыми операциями - проекцией, выборкой, соединением и некоторыми другими;
- ограничениями - функциональными зависимостями между атрибутами отношения.
В основе модели лежат следующие понятия: тип данных, домен, атрибут, схема отношения, кортеж, схема РБД, отношение, первичный ключ.
Домен - множество допустимых значений данного типа.
Атрибут - столбец отношений. Ему присваивается имя и его значения относятся к соответствующему домену.
Каждому классу объектов Р материального мира ставится в соответствие некоторое множество атрибутов, например А1,А2,...,Ап. Отдельный объект класса Р описывается строкой величин (a1, a2,..., an), где ai - значение атрибута Ai.
Строка (a1, a2,..., an) называется кортежем. Всему классу объектов соответствует множество кортежей, называемое отношением. Обозначим отношение, описывающее класс объектов Р, также через Р.
Выражение Р(А1, А2,...,Ап) называется схемой отношения Р.
Схема РБД - представляет собой совокупность схем отношений и содержит следующие компоненты: S(rel) = <A,R,Dom,Rel,V(s)>,
где А - множество имен атрибутов,
R - множество имен отношений,
Dom - вхождение атрибутов в домены,
Rel - вхождение атрибутов в отношения,
V(s) - множество ограничений (в том числе функциональных зависимостей).
Ключ отношения - атрибут (набор атрибутов), значения которого однозначно идентифицируют каждый кортеж отношения.
Первичный ключ - ключ, который содержит минимальный набор атрибутов, ни один из которых нельзя отбросить без потери главного свойства ключа - однозначно идентифицировать кортеж.
1.7 Переход от ER-модели к реляционной модели данных
Переход от инфологической модели “сущность-связь” к реляционной - это сравнительно простая задача, поскольку в терминологии и принципах ER-модели и реляционного подхода имеется взаимно однозначное соответствие. Существует ряд хорошо зарекомендовавших себя правил, с помощью которых из ER-диаграмм откроются реляционные таблицы:
1. Каждая простая сущность превращается в таблицу. Простая сущность - сущность, не являющаяся подтипом и не имеющая подтипов. Имя сущности становится именем таблицы.
2. Каждый атрибут становится возможным столбцом с тем же именем; может выбираться более точный формат. Столбцы, соответствующие необязательным атрибутам, могут содержать неопределенные значения; столбцы, соответствующие обязательным атрибутам, - не могут.
3. Компоненты уникального идентификатора сущности превращаются в первичный ключ таблицы. Если имеется несколько возможных уникальных идентификатора, выбирается наиболее используемый. Если в состав уникального идентификатора входят связи, к числу столбцов первичного ключа добавляется копия уникального идентификатора сущности, находящейся на дальнем конце связи (этот процесс может продолжаться рекурсивно). Для именования этих столбцов используются имена концов связей и или имена сущностей.
4. Связи многие-к-одному и один-к-одному и становятся внешними ключами. Т.е. делается копия уникального идентификатора с конца связи «один», и соответствующие столбцы составляют внешний ключ. Необязательные связи соответствуют столбцам, допускающим неопределенные значения; обязательные связи - столбцам, не допускающим неопределенные значения.
5. Индексы создаются для первичного ключа (уникальный индекс), внешних ключей и тех атрибутов, на которых предполагается в основном базировать запросы.
Если в концептуальной схеме присутствовали подтипы, то возможны два способа:
а) все подтипы в одной таблице (таблица создается для наиболее внешнего супертипа, а для подтипов могут создаваться представления. В таблицу добавляется, по крайней мере, один столбец, содержащий код ТИПА, он становится частью первичного ключа);
б) для каждого подтипа - отдельная таблица (для каждого подтипа первого уровня (для более нижних - представления) супертип воссоздается с помощью представления UNION (из всех таблиц подтипов выбираются общие столбцы - столбцы супертипа).
Имеется два способа работы при наличии исключающих связей:
а) общий столбец (если остающиеся внешние ключи все в одном домене, т.е. имеют общий формат, то создаются два столбца: идентификатор связи и идентификатор сущности. Столбец идентификатора связи используется для различения связей, покрываемых дугой исключения. Столбец идентификатора сущности используется для хранения значений уникального идентификатора сущности на дальнем конце соответствующей связи);
б) явные внешние ключи (если результирующие внешние ключи не относятся к одному домену, то для каждой связи, покрываемой дугой исключения, создаются явные столбцы внешних ключей; все эти столбцы могут содержать неопределенные значения).
1.8 Нормализация отношений
Нормализация отношений (таблиц) -- одна из основополагающих частей теории реляционных баз данных. Нормализация имеет своей целью избавиться от избыточности в отношениях и модифицировать их структуру таким образом, чтобы процесс работы с ними не был обременён различными посторонними сложностями. При игнорировании такого подхода эффективность проектирования стремительно снижается, что вкупе с прочими подобными вольностями может привести к критическим последствиям.
Задача группировки атрибутов в отношения, набор которых заранее не фиксирован, допускает множество различных вариантов решений. Рациональные варианты группировки должны учитывать следующие требования:
- множество отношений должно обеспечивать минимальную избыточность представления информации;
- корректировка отношений не должна приводить к двусмысленности или потере информации;
- перестройка набора отношений при добавлении в базу данных новых атрибутов должна быть минимальной.
Нормализация представляет собой один из наиболее изученных способов преобразования отношений, позволяющих улучшить характеристики БД по перечисленным критериям.
Ограничения на значения, хранимые в реляционной базе данных, достаточно многочисленны. Соблюдение этих ограничений в конкретных отношениях связано с наличием так называемых нормальных форм. Процесс преобразования отношений базы данных к той или иной нормальной форме называется нормализацией отношений. Нормальные формы нумеруются последовательно от 1 по возрастанию, и чем больше номер нормальной формы, тем больше ограничений на хранимые значения должно соблюдаться в соответствующем отношении.
Ограничения, типичные для реляционной модели данных, - это функциональные и многозначные зависимости, а также их обобщения. В принципе, множество дополнительных ограничений может расти и соответственно будет увеличиваться число нормальных форм. Применяемые ограничения ориентированы на сокращение избыточной информации в реляционной базе данных.
Отношение в первой нормальной форме (сокращенно 1НФ) - это обычное отношение с двухуровневой структурой. Недопустимость в структуре отношения третьего и последующих уровней является ограничением, определяющим 1НФ отношения.
Преобразование ненормализованного отношения в представление, соответствующее 1 НФ, - это операция нормализации. Следует отметить определенное терминологическое несоответствие - нормализация приводит к 1НФ, а нормализация отношений реляционной БД обычно производится до ЗНФ или 4НФ.
Реляционная база данных в целом характеризуется 1НФ, если все ее отношения соответствуют 1НФ.
2НФ - отношение находится в 2НФ, если оно находится в 1НФ и каждый не ключевой атрибут полно зависит от первичного ключа. Для перехода из 1НФ в 2НФ нужно:
- взять проекцию исходного отношения на составной первичный ключ и на поля находящиеся в полной функциональной зависимости (ФЗ) от составного ключа;
- взять ещё 1 или проекций на часть составного ключа и на поля ФЗ от этой части ключа.
3НФ - отношение находится в 3НФ, если оно находится в 2НФ и каждый не ключевой атрибут не транзитивно зависит от первичного ключа. Для перехода к 3НФ нужно: разделить отношения на 2 или более проекции так чтобы конечный атрибут в цепочках транзитивной зависимости вынести в разные отношения, связав их внешним ключом по атрибутам, находящимся внутри цепочек транзитивных зависимостей.
НФ Бойса Кода (НФБК) - отношение находится в НФБК, если оно находится в 3НФ и каждый детерминант является возможным ключом. Т.е. если в нём отсутствует зависимый атрибут первичного ключа от не ключевых атрибутов. Для перехода к НФБК нужно разделить отношения на 2 или более проекции так, чтобы исключить в случае пересечения по некоторым атрибутам имеющихся детерминантов. Отношение редко приводят к НФБК т. к. на практике достаточно 3НФ.
1.9 CASE-средства автоматизированного проектирования системы
Изначально CASE-технологии развивались с целью преодоления ограничений при использовании структурной методологии проектирования (сложности понимания, высокой трудоемкости и стоимости использования, трудности внесения изменений в проектные спецификации и т.д.) за счет ее автоматизации и интеграции поддерживающих средств. Таким образом, CASE-технологии не могут считаться самостоятельными, они только обеспечивают, как минимум, высокую эффективность их применения, а в некоторых случаях и принципиальную возможность применения соответствующей методологии. Большинство существующих CASE-систем ориентировано на автоматизацию проектирования программного обеспечения и основано на методологиях структурного (в основном) или объектно-ориентированного проектирования и программирования, использующих спецификации в виде диаграмм или текстов для описания системных требований, связей между моделями системы, динамики поведения системы и архитектуры программных средств. В последнее время стали появляться CASE-системы, уделяющие основное внимание проблемам спецификации и моделирования технических средств.
Наибольшая потребность в использовании CASE-систем испытывается на начальных этапах разработки, а именно на этапах анализа и спецификации требований к ИС. Это объясняется тем, что цена ошибок, допущенных на начальных этапах, на несколько порядков превышает цену ошибок, выявленных на более поздних этапах разработки.
Назначение CASE-средств, представленных сегодня на мировом рынке несколькими сотнями (около 300) продуктов, довольно многообразно: построение и анализ моделей предметной области и интерфейсов, архитектуры, алгоритмов и структур данных, проектирование баз данных и генерация их схем для основных СУБД, разработка приложений и создание их программного кода, реинжиниринг процессов и баз данных и др. В большинстве современных CASE-систем применяются методологии структурного анализа и проектирования, основанные на наглядных диаграммных техниках, при этом для описания модели проектируемой системы используются графы, диаграммы, таблицы и схемы. Такие методологии обеспечивают строгое и наглядное описание проектируемой системы, которое начинается с ее общего обзора и затем детализируется, приобретая иерархическую структуру со все большим числом уровней. Но лишь в узком смысле CASE-средства -это средства визуального моделирования, графический редактор для создания картинок, а в широком -средства, максимально автоматизирующие все процессы жизненного цикла проекта разработки и реализации (как в организационной, так и в программной инженерии). CASE позволяет не только создавать «правильные» продукты, но и обеспечить «правильный» процесс их создания. Основная цель CASE состоит в том, чтобы отделить проектирование ПО от его кодирования и последующих этапов разработки.
CASE-технология в рамках методологии включает в себя методы, с помощью которых на основе графической нотации строятся диаграммы, поддерживаемые инструментальной средой.
Методология определяет шаги и этапность реализации проекта, а также правила использования методов, с помощью которых разрабатывается проект.
Метод - это процедура или техника генерации описаний компонентов ЭИС (например, проектирование потоков и структур данных).
Нотация - отображение структуры системы, элементов данных, этапов обработки с помощью специальных графических символов диаграмм, а также описание проекта системы на формальных и естественных языках.
Инструментальные средства CASE - специальные программы, которые поддерживают одну или несколько методологий анализа и проектирования ИС.
2. Проектирование ИС на примере предметной области
2.1 Предметная область «Отдел сантехники в магазине»
Для создания базы данных необходимо, прежде всего, провести предпроектный анализ предметной области: определить какая информация будет входной, а какая - выходной. Необходимо также учесть информационные потребности пользователей.
Пользователи данной информационной системы (ИС) - сотрудники отдела по продаже сантехники в магазине.
Потребность продавцов - это наличие полного описания всего имеющегося товара при работе с покупателями (тип, марка, цена, количество). Владельцев отдела - контроль продаж каждого продавца и наличия всего ассортимента товара. Бухгалтерии отдела - контроль за поступившим и проданным товаром, составление статистического учета по спросу покупателей.
Задача управления состоит в автоматизации учёта товаров, для покупателей, которые нуждаются в услугах.
Выходной информацией является то, что клиенту выдается кассовый и товарный чек после покупки товара. Также к выходной информации можно отнести статистические отчёты о продаже товара. Для решения этой задачи необходимо создать модель данных на основе, которой будет построена необходимая БД для предметной области «Отдел сантехники в магазине».
Решаемые задачи:
- выдача сведений о товарах (тип, марка, описание, цена);
- учёт товара, его реализации и гарантийного обслуживания;
- создание полной базы данных о товаре;
- формирование статистических отчетов о продаже товара.
Алгоритм решения:
Проданный товар заносится в таблицу как реализуемый. В автоматическом режиме сведения импортируются в базу данных, отражаются на продажах продавцов и количестве товара на складе. Работа ИС продавцами, владельцами и бухгалтерией заключается в получении сводных отчетов из ИС и анализу полученных данных.
2.2 Моделирование данных предметной области
Моделирование базы данных необходимо для того, чтобы выразить сущности предметной области и связи между ними.
В настоящее время большинство проектов автоматизированных рабочих мест разрабатывается в соответствии с какой-либо методологией разработки программного обеспечения. Как следствие, разработчикам требуется инструмент для моделирования данных на этапах анализа и проектирования.
Объединяя частные представления о содержимом базы данных, полученные в результате опроса пользователей, и свои представления о данных, которые могут потребоваться в будущих приложениях, администратор базы данных (АБД) сначала создает обобщенное неформальное описание создаваемой базы данных. Это описание, выполненное с использованием естественного языка, математических формул, таблиц, графиков и других средств, понятных всем людям, работающих над проектированием базы данных, называют инфологической моделью данных [2].
Цель инфологического моделирования - обеспечение наиболее естественных для человека способов сбора и представления той информации, которую предполагается хранить в создаваемой базе данных. Поэтому инфологическую модель данных пытаются строить по аналогии с естественным языком. Основными конструктивными элементами инфологических моделей являются сущности, связи между ними и их свойства (атрибуты).
Описание, создаваемое по инфологической модели данных, называют даталогической моделью данных. Даталогическая модель отражает логические связи между элементами данных вне зависимости от их содержания и среды хранения. Пользователям выделяются подмножества этой логической модели, называемые внешними моделями, отражающие их представления о предметной области. Внешняя модель соответствует представлениям, которые пользователи получают на основе логической модели, в то время как концептуальные требования отражают представления, которые пользователи первоначально желали иметь и которые легли в основу разработки инфологической модели.
Даталогическая модель отображается в физическую память, такую, как диск, лента или какой-либо другой носитель информации. Даталогическая модель в основном используется прикладными программистами для реализации требований, которые выдвинули конечные пользователи, отражённых в инфологической концептуальной модели.
Физическая модель данных - модель, определяющая размещение данных на внешних носителях, методы доступа и технику индексирования. Она так же называется внутренней моделью системы [10].
Внешние модели (даталогические модели) никак не связаны с типом физической памяти, в которой будут храниться данные, и с методами доступа к этим данным. Внутренние модели (физические модели) наоборот определяют и оперируют размещением данных и их взаимосвязях на запоминающих устройствах.
Цель моделирования данных состоит в обеспечении разработчика концептуальной схемой базы данных в форме одной модели или нескольких локальных моделей, которые относительно легко могут быть отображены в любую систему баз данных. Наиболее распространенным средством моделирования данных являются диаграммы «сущность-связь» (ERD). С их помощью определяются важные для предметной области объекты (сущности), их свойства (атрибуты) и отношения друг с другом (связи). ERD непосредственно используются для проектирования реляционных баз данных.
Логическая модель созданная в ErWine представлена на рисунке 2.1.
Рисунок 2.1 Логический уровень модели в ErWin
Переход к физической модели осуществляется в ErWine:
- Сначала в логической модели создаются связи и сущности, вносятся названия и атрибуты сущностей;
- После того как всё построено на логическом уровне переходим на физический. Физическая модель имеет вид, представленный на рисунке 2.2.
Рисунок 2.2 Физический уровень модели в ErWin
После перехода на физическую модель нужно перенести данные в Access. Перенос данных изображен на рисунках 2.3 - 2.4
Рисунок 2.3 Выбор базы данных для Access
Затем в том же районе нажать на кнопку Generate.
Далее в появившемся окне выбрать путь к предварительно созданному документу Access и нажать на кнопку Connect;
Рисунок 2.4 Выбор пути к созданной базе данных Access
Если перенос данных прошёл без ошибок нажать ОК. Теперь можно заполнять таблицы данными и создавать запросы.
Сгенерированная БД в Microsoft Access представлена на рисунке 2.5.
Рисунок 2.5 Сгенерированная БД
2.3 Исходные данные
1. Таблица Товар
2. Таблица Продажа
3. Таблица Продавец
4. Таблица Гарантия
2.4 SQL-запросы для БД
Запрос 1. Название товара, который ни разу не продавался в феврале:
SELECT Товар.[Тип товара], Продажа.[Дата продажи]
FROM Товар INNER JOIN Продажа ON Товар.[Код товара] = Продажа.[Код товара]
GROUP BY Товар.[Тип товара], Продажа.[Дата продажи]
HAVING (((Продажа.[Дата продажи]) Not Like "*" & ".02." & "*"));
Запрос 2. ФИО продавца продавшего наибольшее количество водонагревателей:
SELECT Товар.[Тип товара], Продавец.[ФИО продавца]
FROM Товар INNER JOIN (Продавец INNER JOIN Продажа ON Продавец.[Код проавца] = Продажа.[Код продавца]) ON Товар.[Код товара] = Продажа.[Код товара]
GROUP BY Товар.[Тип товара], Продавец.[ФИО продавца]
HAVING (((Товар.[Тип товара])="Водонагреватель"));
Запрос 3. Характеристики душевой кабины марки Х:
SELECT Товар.[Тип товара], Товар.[Марка товара], Товар.[Описание товара], Товар.[Цена товара]
FROM Товар
WHERE (((Товар.[Тип товара])="Душевая кабина") AND ((Товар.[Марка товара]) Like "*" & [Введите марку Душевой кабины] & "*"));
Запрос 4. Количество товара Х на складе на данный момент:
SELECT [Товар].[Тип товара], SUM([Товар].[Количество товара]) AS сумма
FROM Товар
GROUP BY [Товар].[Тип товара]
HAVING ((([Товар].[Тип товара]) Like [Введите товар] & "*"));
Запрос 5. Душевые кабины по цене не более Х:
SELECT Товар.[Тип товара], Товар.[Цена товара]
FROM Товар
GROUP BY Товар.[Тип товара], Товар.[Цена товара]
HAVING (((Товар.[Тип товара])="Душевая кабина") AND ((Товар.[Цена товара])<=[Введите цену душевой кабины]));
Запрос 6. Вывести дату продаваемого товара Х за январь:
SELECT Продажа.[Дата продажи]
FROM Товар INNER JOIN Продажа ON Товар.[Код товара] = Продажа.[Код товара]
GROUP BY Продажа.[Дата продажи], Товар.[Тип товара]
HAVING (((Продажа.[Дата продажи]) Like "*" & ".01." & "*") AND ((Товар.[Тип товара]) Like [Введите товар] & "*"));
Заключение
Предложны алгоритмы решения поставленных задач, описаны пользователи данной ИС, объекты и их связи.
Была спроектирована логическая модель в среде ERWin, осуществлён переход с логической модели на физическую, перенос данных из ERwina в Access, переходы были описаны.
Описанная задача предназначенная для обработки данных о товарах, их наличии на складе, о проданных товарах, их описании, и гарантийном обслуживании. Система должна выдавать сведения по запросу сотрудников отдела.
...Подобные документы
Понятие информации, автоматизированных информационных систем и банка данных. Общая характеристика описательной модели предметной области, концептуальной модели и реляционной модели данных. Анализ принципов построения и этапы проектирования базы данных.
курсовая работа [1,7 M], добавлен 18.01.2012Описание предметной области "Магазин по продаже компьютерных комплектующих". Построение ER и реляционной модели данных, сущности и связи. Создание ER и реляционной модели данных, запросов, представлений, хранимых процедур для предметной области.
курсовая работа [32,2 K], добавлен 15.06.2014Базы данных - важнейшая составная часть информационных систем. Проектирование базы данных на примере предметной области "Оргтехника". Сбор информации о предметной области. Построение информационно-логической модели данных. Разработка логической структуры.
курсовая работа [318,6 K], добавлен 24.12.2014Изучение реляционной модели данных. Выявление потребности задач в данных и определение состава и структуры информационных объектов. Построение концептуальной модели предметной области. Создание форм, запросов и отчетов с помощью конструктора запросов.
курсовая работа [6,3 M], добавлен 09.10.2021Анализ предметной области, этапы проектирования автоматизированных информационных систем. Инструментальные системы разработки программного обеспечения. Роль CASE-средств в проектировании информационной модели. Логическая модель проектируемой базы данных.
курсовая работа [410,6 K], добавлен 21.03.2011Основные области проектирования информационных систем: базы данных, программы (выполнение к запросам данных), топология сети, конфигурации аппаратных средств. Модели жизненного цикла программного обеспечения. Этапы проектирования информационной системы.
реферат [36,1 K], добавлен 29.04.2010Разработка функциональной модели предметной области. Построение UML диаграмм в среде Pacestar UML Diagrammer. Выбор программных средств разработки. Разработка логической и физической модели данных. Разработка клиентского приложения ИС в среде Access.
курсовая работа [2,2 M], добавлен 09.03.2011Особенности предметной области - накопительной и скидочной системы в магазине продажи одежды. Описание работы системы. Инфологическое проектирование модели базы данных. Схема "сущность-связь", нотация Питера Чена. Проектирование базы данных на языке SQL.
курсовая работа [1,8 M], добавлен 26.02.2016Области применения и реализации информационных систем. Анализ использования Web-технологий. Создание физической и логической модели данных. Проектирование информационных систем с Web-доступом. Функции Института Искусств и Информационных Технологий.
дипломная работа [3,8 M], добавлен 23.09.2013Жизненный цикл информационных систем, методологии и технологии их проектирования. Уровень целеполагания и задач организации, классификация информационных систем. Стандарты кодирования, ошибки программирования. Уровни тестирования информационных систем.
презентация [490,2 K], добавлен 29.01.2023Разработка объектно-ориентированной модели ООО "Мир Компьютеров". Описание предметной области. Разработка функциональной модели системы средствами BPwin. Проектирование информационной системы средствами Rational Rose. Сопровождение информационных сетей.
курсовая работа [843,4 K], добавлен 07.01.2015Жизненный цикл автоматизированных информационных систем. Основы методологии проектирования автоматизированных систем на основе CASE-технологий. Фаза анализа и планирования, построения и внедрения автоматизированной системы. Каскадная и спиральная модель.
курсовая работа [1,1 M], добавлен 20.11.2010Функции автоматизированной системы "Отдел аспирантуры". Проектирование реляционной модели и разработка SQL-кода базы данных. Анализ информационного обеспечения функций. Проектирования глобальной ER-модели. Спецификации локальных ограничений и правил.
курсовая работа [428,4 K], добавлен 01.04.2011Понятие и внутренняя структура, стадии и объекты процесса проектирования баз данных. Требования, предъявляемые к данному процессу. Ограниченность реляционной модели. Группы CASE-средств. Анализ предметной области: функциональный и объектный подходы.
презентация [114,6 K], добавлен 19.08.2013Понятие, модели и назначение информационных систем. Функциональное моделирование ИС. Диаграмма потоков данных. Декомпозиция процессов и миниспецификации. Реализация макета системы средствами MS SQL Server 2005. Создание базы данных. Скалярные функции.
курсовая работа [1,0 M], добавлен 16.09.2012Обоснование использования виртуальной модели, средства для разработки функциональных модулей. Разработка виртуальной модели "Представление знаний в информационных системах". Разработка алгоритмов построения виртуальной модели предметной области.
дипломная работа [1,4 M], добавлен 12.08.2017Классификация информационных систем. Использование баз данных в информационных системах. Проектирование и реализация информационной системы средствами MS Access. Анализ входной информации предметной области и выделение основных информационных объектов.
курсовая работа [2,5 M], добавлен 09.08.2012Модели данных в управлении базами данных. Концептуальные модели данных. Роль баз данных в информационных системах. Реляционная модель данных. Определение предметной области. Построение модели базы данных для информационной системы "Домашние животные".
курсовая работа [1,9 M], добавлен 19.04.2011Определенная логическая структура данных, которые хранятся в базе данных. Основные модели данных. Элементы реляционной модели данных. Пример использования внешних ключей. Основные требования, предъявляемые к отношениям реляционной модели данных.
презентация [11,7 K], добавлен 14.10.2013Описание предметной области. Характеристика этапов разработки концептуальной модели данных для предметной области "Библиотека" с использованием CASE-средства ER Win. Методика преобразования концептуальной модели в физическую структуру базы данных (БД).
курсовая работа [2,4 M], добавлен 23.09.2014
