В файловых системах одновременная работа нескольких пользователей, связанная с модификацией данных в файле либо вообще не реализовывалась, либо была замедлена. Эти недостатки привели к разработке новых подходов к управлению информации. Этот подход был реализован в рамках новых программных средств и называется системой управления базой данных (СУБД), а сами хранилища информации назывались базами данных и банками данных. Одним из первых этапов создания базы данных – это были большие ЭВМ. Первые СУБД были даны в эксплуатацию фирмой IBM в конце 60-х годов. Эта СУБД была связана с организацией базы данных на больших ЭВМ (360) и ЕС (Единая система). Здесь базы данных хранились во внешней памяти центрального ЭВМ. Пользовательскими задачами были запуск данных в пакетном режиме. Мощные операционные системы параллельно обеспечивали множество задач. Эти системы можно было отнести к системе распределённого доступа, потому что база данных была централизованной. Хранилась на установленной внешней памяти одной из центрального ЭВМ, а доступ к ней поддерживался от многих пользователей и задач.
В дальнейшем в теории базы данных был сделан большой вклад американским математиком Эдвардом Коддом, который являлся создателем теории реляционной базы данных и в то же время появились языки высокого уровня.
Второй этап – это эпоха персональных компьютеров. В это время появились программы, которые назывались СУБД и позволяли хранить значительный объём информации. Они имели удобный интерфейс для заполнения базы данных. Они позволяли автоматизировать множественные функции, которые ранее велись вручную. Первые базы данных на компьютерах были недолговечны, т.е. они не учитывали взаимосвязи реальных объектов и спрос на удобные программы СУБД. Это привело к созданию настольных СУБД. При этом каждый разработчик разрабатывал собственные СУБД , используя стандартные языки программирования и таким образом каждый раз приходилось набранные данные переносить на более новый СУБД. Это было одно из основных недостатков этой эпохи. Яркие представители этой эпохи были: dbase, FoxPro, clipper, Paradox.
Третий этап распределения базы данных. В этом этапе появилось большое количество локальных сетей, все больше информации передаются между компьютерами и встаёт задача о согласовании данных , хранящихся и обрабатываемых в разных местах, но которые логически связаны друг с другом. Решение этой задачи приводит к появлению распределённой базы данных, сохраняющих преимущество всех настольных СУБД, но в тоже время позволяющих организовать параллельную обработку информации. Именно на этом этапе были начаты работы связанные с концепцией объектно ориентированной базы данных (SQL). Для манипулирования данными на этом этапе был использован SQL и технологии по обмену данными между СУБД, к которым можно отнести ODBC (open database connectivity). Именно на этом этапе были представлены MsAccess, MsSQL,ORCL и т.д.
Четвёртый этап- перспективы развития СУБД. Он характерен новой технологией доступа к данным intronet. При этом отпадают необходимости использования специального клиентского программного обеспечения. Для работы с удалённой базой данных используют стандартные браузеры Интернет Explorer и т.д. При этом встроенный в загруженный пользователями html страницы код, написан на языках java, JavaScript отлаживает все действия пользователя и транслируют их в низкоуровневые SQL запросы. Таким образом выполняется клиентская программа. Удобства такого подхода позволило использовать его не только в удалённые базы данных, но и в локальных сетях предприятий.
Основные понятия и определение базы данных
Очень часто упоминается термин банк и база данных и они отличаются. База данных- именованная совокупность данных, отражённых состояний объектов и их отношений в рассмотренной предметной области. Под предметной областью понимают одну или несколько объектов управления информации которых моделируются с помощью базы данных и используются для решения различных функциональных задач. Система управления базы данных совокупность языков и программных средств, предназначенных для создания введения и совместного использования базы данных многими пользователями. СУБД должен обеспечивать независимость данных. Практически одна и та же СУБД может быть использована для введения разных файлов, которые используются для решения различных не связанных между собой задач управления. Все функции СУБД можно объединить в такие группы:
1) Управление данными. Задачами управления данных являются подготовка и контроль данных, внесения данных в базу данных, обеспечение целостности и секретности данных.
2) Доступ к данным. Поиски, селекция данных, преобразование данных в форму удобную для дальнейшего использования.
3) Организация и ведение связи с пользователями, ведение диалога. Выдача данных сообщений об ошибках в работе по базе данных и т.д. Для обработки запросов к базе данных, разработка программ, которые представляются как прикладные программы с помощью которых пользователь работает с базой данных, называемой приложением. В принципе с одной базой данных могут работать множество различных приложений . Именно СУБД обеспечивает работу с единой базой данных таким образом, что каждая из них выполняется корректно и учитывает все изменения в приложении.
Этапы проектирования базы данных
Вопрос проектирования базы данных выделяется как отдельное направление работ при разработке информационных систем проектирование базы данных- это итерационный многоэтапный процесс принятия решения в процессе анализа информационной модели предметной области. Здесь должны быть учтены требования к данным со стороны прикладного программирования и пользователя, логичных и функциональных структур данных, выбор программ и аппаратных средств. Этапы проектирования базы данных связаны с многоуровневой организацией данных. Многоуровневый процесс данных состоит в следующем: внешнее, инфологическое, логическое, даталогическое, внутреннее. Существуют и другие уровни представления данных, где используются 3 уровня: внешний, концептуальный, внутренний.
Внешний уровень необходим для реализации какого-либо запроса или прикладного программирования. Иногда внешний уровень считают и инфологическим, т.е. при этом изучаются все вне машинные информационные обеспечения, т.е. формы документирование и представление данных, а также внешняя среда, где будет функция базы данных. Внешний уровень- это описание входных и выходных сообщений и данных, которые целесообразно хранить в базе данных. Описание внешнего уровня не исключает наличия элементов дублирования избыточности и несогласия данных. Для устранения этих противоречий применено инфологическое проектирование. Инфологическую модель можно рассматривать как средство документирования формы представления информационных потребностей, которая обеспечивает непротиворечивые общения пользователя и разработчика системы. Все внешние представления интегрируются на информационном уровне, где инфологический уровень представляет собой инфологическую модель предметной области из которой исключена избыточность данных и отображение информационной особенности объектов управления, т.е. инфологическое представление данных, ориентированных на человека, который проектирует или использует базу данных.
На этом уровне формируется концептуальная модель данных, которая отвечает особенностям и ограничениям выбранного СУБД. Эта модель ориентирована на программистов. Модель логического уровня, которая поддерживает конкретизацию средств СУБД, называется даталогической. Инфологическая и даталогическая модели зависимы между собой. Инфологическая модель может легко трансформироваться в даталогическую. Внутренний уровень связан с физическим размещением данных. От параметров физической модели зависит объём памяти и время реакции системы. Физические пара
| Внешний уровень данных |
-словесное описание данных и их взаимосвязи.
↓
| Инфологический уровень данных |
-строится инфологическая и логическая модель без описания СУБД.
↓
| Логический уровень данных |
-отражает информационные логические модели на базе данных подчиняющихся СУБД.
↓
| Внутренний уровень данных |
-размещение данных в памяти их характеристика и пути доступа к ним.
Понятие модели данных
Существую 3 вида модели:
1) Иерархическая
2) Сетевая
3) Реляционная
Иерархическая база данных имеет древовидную структуру и состоит из упорядоченного набора поддеревьев. Тип дерева состоит из одного корневого типа записи и более типов поддеревьев.
Сетевая модель. Если в отношении между данными имеется более одного соединения, то это отношение описывается в виде сетевой структуры. Сетевая база данных состоит из набора и множества связи между ними.
Реляционная модель в отличие от иерархической и сетевой моделей не имеет недостатков. Для того, чтобы база данных более эффективно функционировала предложим реляционный подход. Создание реляционной модели связано с именем Эдварда Кодда. Первые работы в этой области появились в 70-х годах и очень долгое время этот подход являлся удобным формальным аппаратом анализа базы данных.
Своё начало реляционный подход берёт из теории множества математики. В реляционной модели объекты и их взаимосвязи представлены с помощью таблиц. Взаимосвязи также рассмотрим как объекты. Каждая таблица представляет собой объект. В терминологии реляционные модели таблиц называются отношением, каждый столбец в таблице называется атрибутом значения в столбце выделенный из домена. Домен- это множество значений, который может принимать каждый атрибут. Строки таблицы называются кортежами.
| № страницы |
Фамилия |
Имя |
Год рождения |
Место рождения |
| 8009 |
Мамедов |
Рза |
1990 г. |
Баку |
Домен
↓
→ атрибут
кортёж→
Таким образом построенная база данных имеет первую нормальную форму, т.е. для каждого атрибута выбран тип и длина записи. К достоинствам реляционной модели следует отнести простоту общения пользователя с моделью. Недостаток модели обычной реляционной системы- работает медленнее, чем сетевые и иерархические. В реляционной модели также используется первичный ключ. Это столбец, значения которого во всех строках различный. Первичные ключи могут объединять несколько столбцов. В некоторых СУБД первичный ключ может задаваться системой (Access).
Связь реализуется при помощи внешнего ключа. Внешний ключ- это столбец таблицы значений, которые совпадают со значениями первичного ключа другой таблицы. Важным моментом также является значение null (0) в таблице. При этом значении это поле обрабатывается особым образом.
Для построения реляционной модели используют табличный способ представления данных типа отношения. Наименование единица в реляционной модели- это отдельная атомарная для данных моделей. Множество атомарных значений формируют домен. Отношением на доменах D1,D2…….Dn составленных из заголовка n тела отношений. Заголовок состоит из множества атрибутов ,A1…….An, в которых существует однозначное соответствие между этими атрибутами Ai и определяют их доменами Di. Тело отношения состоит из меняющейся во времени множества кортежей, где каждый кортеж в свою очередь состоит из множества пар атрибут -значений (Ai:Vi). Для любой заданной пары атрибут –значением Vi является значением из единственного домена Di, который связан с атрибутом Ai. Степень отношения – это число его атрибутов. Отношения – это число его кортежей. Ключом отношений является его уникальность. Т.е. никакие два различных кортежа не имеют одного и того же значения для входящих в ключ атрибутов. Ни один из атрибутов, входящий в ключ, не может быть исключён без нарушения уникальности. Каждое отношение обладает хотя бы одним ключом. Один из возможных ключей принимают за первичный, остальные называются альтернативными ключами. Основная цель проектирования базы данных- сокращение избыточности базы данных и экономии объёма используемой памяти. Нормализация – это разделение таблицы на две и более обладающие лучшими свойствами при включении изменений и удаление данных.
страхование база данный
ПРАКТИЧЕСКАЯ ЧАСТЬ
Рассмотрим данные для создания базы данных на тему «Страхование населения». Создаем базу в реляционной модели базы данных.
Описание данной задачи: «Руководство страховой компании заказало разработку информационной системы для отдела работы с клиентами. Система предназначена для обработки данных, о видах страховок, их стоимость, о совершенных сделках, о клиентах, сроках действия страховки. Система должна выдавать отчеты по запросу менеджера: прайс лист по видам страховки, бланк страхования, информацию о клиентах».
Для начала требуется создать таблицу, включающую все вышеуказанные данные в себя. Таблица создается с помощью “создание таблицы в режиме конструктора”:
После создания таблицы создаём форму для данной таблицы при помощи “мастера создания форм”. Добавляем всё содержимое таблицы, создаём внешний вид формы, требуемый стиль, задаём имя формы и она готова:
Затем создаём требуемые в данной задаче запросы в режиме SQL:
SELECT Общая. номер, Общая.[ИФО клиента], Общая.[Год рождения], Общая. Адресс FROM Общая;
SELECT Общая.[вид страховки], Общая.[стоимость страховки] FROM Общая;
После следует создать отчёты на составленные запросы. Отчёты должны составляться по прайс листу по видам страховки, по бланку страхования и отчёт информации о клиентах. Отчёт создаётся следующим образом:
Создание отчёта с помощью мастера→ выбираем поля для отчёта→ добавляем уровни группировок и расставляем в нужной последовательности данные→ задаём требуемый порядок сортировки→ выбираем вид макета для отчёта→ выбираем требуемый стиль→ задаём имя и отчёт готов:
Страница № 1.1
Страница № 1.2
Страница № 1.3
Так же и второй отчёт на запрос прайс листа по видам страховок:
Страница № 2.1
Страница № 2.2
Таким образом наше задание выполнено и завершено.