Главная страница

Садержимое. 1 Анализ предметной области 1 Описание предметной области и функции решаемых задач


Скачать 454.71 Kb.
Название1 Анализ предметной области 1 Описание предметной области и функции решаемых задач
Дата01.05.2022
Размер454.71 Kb.
Формат файлаdocx
Имя файлаСадержимое.docx
ТипДокументы
#506458
страница1 из 2
  1   2

Введение

4

1 Анализ предметной области




1.1 Описание предметной области и функции решаемых задач




1.2 Перечень входных данных




1.3 Перечень выходных данных




1.4 Ограничения предметной области




1.5 Взаимодействие с другими программами




1.6 Постановка задачи




2 Проектирование концептуальной модели




2.1 Выделение информационных объектов




2.2 Определение атрибутов объектов




2.3 Определение отношений и мощности отношений между объектами




2.4 Построение схемы концептуальной модели




3 Разработка логической структуры базы данных




4 Реляционная модель




5 Определение типов данных в заданном формате




6 Создание глобальной схемы связей. Поддержка целостности данных



7 Запросы. Структура и назначение. SQL – запрос





8 Проектирование форм. Структура и назначение существующих форм



9 Структура отчетов




10 Макросы. Назначение и алгоритм работы





11. Структура главной кнопочной формы.




12 Руководство пользователя




Заключение




Список использованных источников






СОДЕРЖАНИЕ

ВВЕДЕНИЕ

База данных — это упорядоченный набор структурированной информации или данных, которые обычно хранятся в электронном виде в компьютерной системе. База данных обычно управляется системой управления базами данных (СУБД). Данные вместе с СУБД, а также приложения, которые с ними связаны, называются системой баз данных, или, для краткости, просто базой данных.

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

Базы данных значительно изменились с момента их появления в начале 1960-х годов. Исходными системами, которые использовались для хранения и обработки данных, были навигационные базы данных – например, иерархические базы данных (которые опирались на древовидную модель и допускали только отношение «один-ко-многим») и базы данных с сетевой структурой (более гибкая модель, допускающая множественные отношения). Несмотря на простоту, эти ранние системы были негибкими. В 1980-х годах стали популярными реляционные базы данных, в 1990-х годах за ними последовали объектно-ориентированные базы данных. Вследствие роста Интернета и возникновения необходимости анализа неструктурированных данных появились базы данных NoSQL. В настоящее время облачные базы данных и автономные базы данных открывают новые возможности в отношении способов сбора, хранения, использования данных и управления ими.

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

- Реляционные базы данных стали преобладать в 1980-х годах. Данные в реляционной базе организованы в виде таблиц, состоящих из столбцов и строк. Реляционная СУБД обеспечивает быстрый и эффективный доступ к структурированной информации.

- Информация в объектно-ориентированной базе данных представлена в форме объекта, как в объектно-ориентированном программировании.

- Распределенная база данных состоит из двух или более частей, расположенных на разных серверах. Такая база данных может храниться на нескольких компьютерах.

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

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

Принципы построения баз данных

К современным базам данных, а, следовательно, и к СУБД, на которых они строятся, предъявляются следующие основные требования:

- Высокое быстродействие (малое время отклика на запрос). Время отклика - промежуток времени от момента запроса к БД до фактического получения данных.

- Простота обновления данных.

- Независимость данных - возможность изменения логической и физической структуры БД без изменения представлений пользователей.

- Совместное использование данных многими пользователями.

- Безопасность данных - защита данных от преднамеренного или непреднамеренного нарушения секретности, искажения или разрушения.

- Стандартизация построения и эксплуатации базы данных (фактически СУБД).

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

- Простой интерфейс пользователя.

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

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

- отсутствие неточно введенных данных или двух одинаковых записей об одном и том же факте;

- защиту от ошибок при обновлении БД;

- невозможность удаления (или каскадное удаление) связанных данных разных таблиц;

- не искажение данных при работе в многопользовательском режиме и в распределенных базах данных;

- сохранность данных при сбоях техники (восстановление данных).

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

- введением системы паролей;

- получением разрешений от администратора базы данных (АБД);

- запретом от АБД на доступ к данным;

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

Стандартизация обеспечивает преемственность поколений СУБД, упрощает взаимодействие базы данных одного поколения СУБД с одинаковыми и различными моделями данных. При этом может быть осуществлен как локальный, так и удаленный доступ к данным (технология клиент/сервер или сетевой вариант).[6]

Проектирование баз данных - процесс решения класса задач, связанных с созданием баз данных

Основные задачи проектирования баз данных:

- Обеспечение хранения в базе данных всей необходимой информации.

- Обеспечение возможности получения данных по всем необходимым запросам.

- Сокращение избыточности и дублирования данных.

  1. АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ

1.1 Описание предметной области и функции решаемых задач

Для более эффективного управления отслеживанием и продажей телефонов было разработано реляционная система учёта мониторинга рынка.

Сотрудники оформляют базу данных продаж для покупателей.

1.2 Перечень входных данных

Входную информацию делят на условно-постоянную, сохраняющую свои значения на длительный период времени, и на постоянно-меняющуюся оперативно-учётную.

Входная информация может быть представлена следующими документами:

Телефоны:

Таблица 1 – Входные данные по телефонам


Название

Память (GB)

Оперативная память (GB)

Камера (МР)

Аккумулятор (KL)

Материал

Фото



Сети продаж:

Таблица 2 – Входные данные по Сетям продаж

Название сети

телефон

цена

скидки

Гарантия

Стоимоимость

Код продажи

Адрес


1.3 Перечень выходных данных

Выходная информация представляется в виде отчётов: Выходную информацию представим в виде отчётных форм:



1.4 Ограничения предметной области

По рассматриваемой предметной области введём некоторые ограничения:

- в таблице «Телефоны» значение поля «Память (GB)» должно быть меньше 512.

1.5 Взаимодействие с другими программами

Представленная информационная успеваемость должна выводить отчёты в текстовый редактор MS Word. Успеваемость 2 курса выводится в MS Excel.

1.6 Постановка задачи

Разрабатываемая информационная система предназначена для структурированного хранения данных и вывода информации о мониторинге и продаже, телефонов.

Разрабатываемая информационная система должна выполнять следующие функции:

- название телефона

- характеристики телефона

- место продажи

- стоимость

2 ПРОЕКТИРОВАНИЕ КОНЦЕПТУАЛЬНОЙ МОДЕЛИ

2.1 Выделение информационных объектов

Одним из первых объектов можно выделить «Телефоны» и «Сети продаж». Для более удобного отслеживания купли продажи телефонов вводим объект «Продажи». Для определения купли продажи аксессуаров и услуг вводим объект «вид отчетности».
2.2 Определение атрибутов объектов

Рассмотрим атрибуты перечисленных объектов.

Объект

Атрибуты объектов

Ключевой атрибут

Телефоны

Название, память (GB), оперативная память (GB), камера (МР), аккумулятор (KL), материал, фото.

Название


Сети продаж

Название сети, телефон, цена, скидка, гарантия, стоимость, код продажи, адрес.




Продажи

Код продажи, дата продажи, место продажи, ФИО покупателя

Код продажи

Покупатели

ФИО,Чехол, Sim-карта, Дата покупки, Код покупки

ФИО

Таблица 3. Перечисленных объектов.

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

Рассмотрим взаимосвязи между объектами и мощности отношение и построим матрицу отношений.

Телефоны -> Сети продаж. «Телефоны» главный объект, а «Сети продаж» подчинённый объект. Тип связи «один ко многим». Так как в одном магазине может быть несколько телефонов. Связь между этими объектами осуществляет атрибут «Название» см. рисунок 2.



Рисунок 2 – Связь между объектами Телефоны -> Сети продаж
Сети продаж -> Продажи. «Продажи» главный объект, а «Сети продаж» подчинённый объект. Тип связи «один ко многим». Так как в одном магазине может быть несколько продаж. Связь между этими объектами осуществляет атрибут «Код продажи» см. рисунок 3.


Рисунок 3 – Связь между объектами Сети продаж -> Продажи

Продажи -> Покупатели. «Покупатели» главный объект, а «Продажи» подчинённый объект. Тип связи «один ко многим». Так как в одном магазине может быть несколько покупателей. Связь между этими объектами осуществляет атрибут «ФИО» см. рисунок 4.



Таблица 4 – Матрица смежности.




Телефоны

Сети продаж

Продажи

Покупатели

Телефоны

0

1:N

0

0

Сети продаж

N:1

0

N:1

0

Продажи

0

1:N

0

N:1

Покупатели

0

0

1:N

0



2.4 Построение схемы концептуальной модели

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



Рисунок 9 – Концептуальная модель

3 РАЗРАБОТКА ЛОГИЧЕСКОЙ СТРУКТУРЫ БАЗЫ ДАННЫХ

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

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

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


Телефоны



Материал

Материал

Аккумулятор(KL)

Камера (МР)

ОП (GB)

Название

Память (GB)







Адрес

Код продажи

Стоимость

Гарантия




Рисунок 7 – Логическая структура реляционной базы

4 РЕЛЯЦИОННАЯ МОДЕЛЬ

Реляционная модель - совокупность данных, состоящая из набора двумерных таблиц. В теории множеств таблице соответствует термин отношение (relation), физическим представлением которого является таблица, отсюда и название модели – реляционная. Соответственно теория построения баз данных, которая является приложением к задачам обработки данных таких разделов математики, как теория множеств и логика первого порядка. В сравнении с иерархической и сетевой моделью данных, реляционная модель отличается более высоким уровнем абстракции данных. Реляционная модель является удобной и наиболее привычной формой представления данных, так в настоящее время эта модель является фактическим стандартом, на который ориентируются практически все современные коммерческие СУБД. На реляционной модели данных строятся реляционные базы данных.

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

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

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

В целостной части реляционной модели данных фиксируются два базовых требования целостности, которые должны поддерживаться в любой реляционной СУБД. Первое требование называется требованием целостности сущностей. Объекту или сущности реального мира в реляционных БД соответствуют кортежи отношений. Конкретно требование состоит в том, что любой кортеж любого отношения отличим от любого другого кортежа этого отношения, т.е. другими словами, любое отношение должно обладать первичным ключом. Как мы видели в предыдущем разделе, это требование автоматически удовлетворяется, если в системе не нарушаются базовые свойства отношений.

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

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

В реляционной модели данных применяются разделы реляционной алгебры, откуда и была заимствованна соответствующая терминология.В реляционной алгебре поименованный столбец отношения называется атрибутом, а множество всех возможных значений конкретного атрибута – доменом. Строки таблицы со значениями разных атрибутов называют кортежами. Атрибут, значение которого однозначно идентифицирует кортежи, называется ключевым (или просто ключом). Так ключевое поле – это такое поле, значения которого в данной таблице не повторяется. В отличие от иерархической и сетевой моделей данных в реляционной отсутствует понятие группового отношения. Для отражения ассоциаций между кортежами разных отношений используется дублирование их ключей. Сложный ключ выбирается в тех случаях, когда ни одно поле таблицы однозначно не определяет запись.

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

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

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

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

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

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

Телефоны (Название, Память(GB), Оперативная память(GB), Камера(MP), Аккумулятор, материал, фото). Внешний ключ: Название.

Сети продаж (Название сети, телефон, цена, скидка, гарантия, стоимость, код продажи, адрес.). Внешний ключ: отсутствует.

Продажи (Код продажи, дата продажи, место продажи, ФИО покупателя). Внешний ключ: Код продажи.

Покупатели (ФИО, Чехол, Sim-карта, Дата покупки, Код покупки ) Внешний ключ: ФИО.
5 ОПРЕДЕЛЕНИЕ ТИПОВ ДАННЫХ В ЗАДАННОМ ФОРМАТЕ

Таблица «Телефоны»

Содержит информацию о телефонах

Таблица 5 – Структура таблицы данных «Телефоны»

Наименование поля

Тип поля

Размер поля

Обязательное поле


Ключевое поле

Название

Текстовый

255

Нет

да

Память (GB)

Числовой

Длинное целое

Нет

Нет

Оперативная память (GB)

Числовой

Длинное целое

Нет

Нет

Камера (MP)

Числовой

Длинное целое

Нет

Нет

Акумулятор (KL)

Числовой

Длинное целое

Нет

Нет

Материал

Текстовый

255

Нет

Нет

Фото

Поле объекта OLE




Нет

Нет


Таблица «Сети продаж»

Содержит информацию о местах продаж телефонов а также их стоимости

Таблица 6 – Структура таблицы данных «предметы»

Наименование поля

Тип поля

Размер поля

Обязательное поле


Ключевое поле

Название сети

Текстовый

255

Нет

Нет

Телефон

Текстовый

255

Нет

Нет

Цена

Денежный




Нет

Нет

Скидка

Текстовый

255

Нет

Нет

Гарантия

Текстовый

255

Нет

Нет

Стоимоимость

Вычисляемый




Нет

Нет

Код продажи

Текстовый

255

Нет

Нет

Адрес

Текстовый

255

Нет

Нет


6 СОЗДАНИЕ ГЛОБАЛЬНОЙ СХЕМЫ СВЯЗЕЙ. ПОДДЕРЖКА ЦЕЛОСТНОСТИ ДАННЫХ

Связи между данными, хранимыми в разных отношениях, в реляционной БД устанавливаются с помощью использования внешних ключей — для установления связи между кортежем из отношения A с определённым кортежем отношения B в предусмотренные для этого атрибуты кортежа отношения A записывается значение первичного ключа (а в общем случае значение потенциального ключа) целевого кортежа отношения B. Таким образом, всегда имеется возможность выполнить две операции:

- определить, с каким кортежем в отношении B связан определённый кортеж отношения A;

- найти все кортежи отношения A, имеющие связи с определённым кортежем отношения B.



Рисунок 8 – Схема данных.

7 ЗАПРОСЫ. СТРУКТУРА И НАЗНАЧЕНИЕ. SQL – ЗАПРОС

Запросы используются пользователем для выбора из базы данных информации, которая интересует его в данный момент. Результат выполнения запроса представляет собой таблицу и называется динамическим или временным набором данных. В эту таблицу включены выбранные из основной таблицы записи, которые удовлетворяют критериям запроса. Как только запрос будет закрыт, динамический набор данных ликвидируется, хотя данные, которые пользователь видел в нем, останутся в исходной таблице. Таким образом, при каждом выполнении запроса он строится на основе «свежих» табличных данных.

Существуют следующие типы запросов:

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

- параметрические запросы;

- перекрестные запросы;

- запросы с записями без подчиненных;

- модифицирующие запросы.

Запрос можно создавать самостоятельно, с использованием конструктора, или же воспользоваться мастером запросов. При самостоятельной разработке нового запроса необходимо в режиме конструктора выбрать таблицы, содержащие нужные данные и заполнить бланк запроса нужными полями (перетащить).

Запросы некоторых типов создаются с помощью мастеров Microsoft Access. Мастер запросов ускоряет процесс создания запроса, автоматически выполняя все основные операции. Вызванный мастер запросов запрашивает сведения и создает запрос на основе ответов пользователя. Затем можно перейти в режим конструктора и доработать запрос.
  1   2


написать администратору сайта