Современная жизнь немыслима без эффективного управления. Важной категорией являются системы обработки информации, от которых во многом зависит эффективность работы любого предприятия ли учреждения. Такая система должна:
- обеспечивать получение общих и/или детализированных отчетов по итогам работы;
- позволять легко определять тенденции изменения важнейших показателей;
- обеспечивать получение информации, критической по времени, без существенных задержек;
- выполнять точный и полный анализ данных.
Современные системы управления базами данных (СУБД) в основном являются приложениями Windows, так как данная среда позволяет более полно использовать возможности персональной ЭВМ, нежели среда DOS. Снижение стоимости высокопроизводительных ПК обусловил не только широкий переход к среде Windows, где разработчик программного обеспечения может в меньше степени заботиться о распределении ресурсов, но также сделал программное обеспечение ПК в целом и СУБД в частности менее критичными к аппаратным ресурсам ЭВМ.
Среди наиболее ярких представителей систем управления базами данных можно отметить: Lotus Approach, Microsoft Access, Borland dBase, Borland Paradox, Microsoft Visual FoxPro, Microsoft Visual Basic, а также баз данных Microsoft SQL Server и Oracle, используемые в приложениях, построенных по технологии «клиент-сервер». Фактически, у любой современной СУБД существует аналог, выпускаемый другой компанией, имеющий аналогичную область применения и возможности, любое приложение способно работать со многими форматами представления данных, осуществлять экспорт и импорт данных благодаря наличию большого числа конвертеров. Общепринятыми, также, являются технологии, позволяющие использовать возможности других приложений, например, текстовых процессоров, пакетов построения графиков и т.п., и встроенные версии языков высокого уровня (чаще – диалекты SQL и/или VBA) и средства визуального программирования интерфейсов разрабатываемых приложений. Поэтому уже не имеет существенного значения на каком языке и на основе какого пакета написано конкретное приложение, и какой формат данных в нем используется. Более того, стандартом «де-факто» стала «быстрая разработка приложений» или RAD (от английского Rapid Application Development), основанная на широко декларируемом в литературе «открытом подходе», то есть необходимость и возможность использования различных прикладных программ и технологий для разработки более гибких и мощных систем обработки данных. Поэтому в одном ряду с «классическими» СУБД все чаще упоминаются языки программирования Visual Basic 4.0 и Visual C++, которые позволяют быстро создавать необходимые компоненты приложений, критичные по скорости работы, которые трудно, а иногда невозможно разработать средствами «классических» СУБД. Современный подход к управлению базами данных подразумевает также широкое использование технологии «клиент-сервер».
Системы управления базами данных
... наиболее ярких представителей систем управления базами данных можно отметить: Lotus Approach, Microsoft Access, Borland dBase, Borland Paradox, Microsoft Visual FoxPro, Microsoft Visual Basic, а также баз данных Microsoft SQL Server и Oracle, используемые в приложениях, построенных по ...
Таким образом, на сегодняшний день разработчик не связан рамками какого-либо конкретного пакета, а в зависимости от поставленной задачи может использовать самые разные приложения. Поэтому, более важным представляется общее направление развития СУБД и других средств разработки приложений в настоящее время.
2. БАЗЫ ДАННЫХ
И СИСТЕМЫ УПРАВЛЕНИЯ ИМИ
2.1. Базы данных
баз данных
База данных (БД)
данные,
Первые БД появились уже на заре 1-го поколен я ЭВМ представляя собой отдельные файлы данных или их простыеcoво купности.
Создавая базу данных, пользователь стремится упорядочить информацию по различным признакам и быстро извлекать выборку с произвольным сочетанием признаков. Сделать это возможно, только если данные структурированы.
Структурирование
Неструктурированными называют данные, записанные, например, в текстовом файле.
Пользователями базы данных могут быть различные прикладные программы, программные комплексы, а также специалисты предметной области, выступающие в роли потребителей или источников данных, называемые конечными пользователями .
2.1. Структурные элементы базы данных
Понятие базы данных тесно связано с такими понятиями структурных элементов, как поле, запись, файл (таблица).
Поле
- имя, например. Фамилия, Имя, Отчество, Дата рождения;
- тип, например, символьный, числовой, календарный;
- длина, например, 15 байт, причем будет определяться максимально возможным количеством символов;
- точность для числовых данных, например два десятичных знака для отображения дробной части числа.
Запись
Файл (таблица
ключами первичными
2.2. Системы управления базами данных
системы управления базами данных
Система управления базами данных (СУБД)
Первые СУБД, поддерживающие и ведение БД, появились в конце 60-х годов.
Использование СУБД обеспечивает лучшее управление данными, более совершенную организацию файлов и более простое обращение к ним по сравнению с обычными способами хранения информации.
3. МОДЕЛИ ДАННЫХ
И ИХ ВИДЫ
Ядром любой базы данных является модель данных. Модель данных представляет собой множество структур данных, ограничений целостности и операций манипулирования данными. С помощью модели данных могут быть представлены объекты предметной области и взаимосвязи между ними.
Модель данных
иерархической, сетевой или реляционной
Однако различия между моделями постепенно стираются, что обусловлено п режде всего интенсивными работами в области баз знаний (БЗ) и объектно-ориентированной инфотехнологие й, о которой будет идти речь ниже.
Каждая из указанных моделей обладает характеристиками, делающими ее наиболее удобной для конкретных приложений. Одно из основных различий этих моделей состоит в том, что для иерархических и сетевых СУБД их структура часто не может быть изменена после ввода данных, тогда как для реляционных СУБД структура может изменяться в любое время. С другой стороны, для больших БД, структура которых остается длительное время неизменной, и постоянно работающих с ними приложений с интенсивными потоками запросов на БД-обслуживание именно иерархические и сетевые СУБД могут оказаться наиболее эффективными решениями, ибо они могут обеспечивать более быстрый доступ к информации БД, чем реляционные СУБД.
4. ИЕРАРХИЧЕСКАЯ
МОДЕЛЬ ДАННЫХ
Иерархическая структура представляет совокупность элементов, связанных между собой по определенным правилам. Объекты, связанные иерархическими отношениями, образуют ориентированный граф (перевернутое дерево).
К основным понятиям иерархической структуры относятся: уровень, элемент (узел), связь.
Узел
К каждой записи базы данных существует только один (иерархический) путь от корневой записи.
 |
Каждому узлу структуры соответствует одинсегмент , представляющий собой поименованный линейный кортежполейданных. Каждому сегменту (кроме S1-корневого) соответствует один входной и несколько выходных сегментов. Каждыйсегмент структуры лежит на единственном иерархическом пути, начинающемся откорневого сегмента.
Следует отметить, что в настоящее время не разрабатываются СУБД, поддерживающие на концептуальном уровне только иерархические модели. Как правило, использующие иерархический подход системы, допускают связываниедревовидных структур между собой и/или установление связей внутри них. Это приводит к сетевым моделям СУБД.
сетевые
5. СЕТЕВАЯ
МОДЕЛЬ ДАННЫХ
В сетевой структуре при тех же основных понятиях (уровень, узел, связь) каждый элемент может быть связан с любым другим элементом.
Сетевая модель СУБД во многом подобна иерархической если в иерархической модели для каждого сегмента записи допускается только один входной сегмент при N выходных, то в сетевой модели для сегментов допускается несколько входных сегментов наряду с возможностью наличия сегментов без входов с точки зрения иерархической структуры.
Графическое изображение структуры связей сегментов такого типа моделей представляет собой сеть. Сегменты дан ых в сетевых БД могут иметь множественные связи с сегментами старшего уровня. При этом направление и характер связи в сетевых БД не являются столь очевидными, как в случае иерархических БД. Поэтому имена и направление связей должны идентифицироваться при описании БД.
Таким образом, под сетевой СУБД понимается система, поддерживающая сетевую организацию: любая запись, называемая записью с а р ш его уровня, может содержать данные, которые относятся к набору других записей, называемых записями подчиненного уровня. Возможно обращение ко всем записям в наборе, начиная с записи старшего уровня. Обращение к набору записей реализуется по указателям.
В рамках сетевых СУБД легко реализуются и иерархические модели.
Сетевые СУБД поддерживают сложные соотношения между типами данных, что делает их пригодными во многих различных приложениях. Однако пользователи таких СУБД ограничены связями, определенными для них разработчиками БД-приложений.
Более того, подобно иерархическим сетевые СУБД предполагают разработку БД приложений опытными программистами и системными аналитиками.
Среди недостатк сетевых СУБД следует особо выделить проблему обеспечения сохранности информации в БД, решению которой уделяется повышенное вн имание при проектировании сетевых БД.
6. РЕЛЯЦИОННАЯ
МОДЕЛЬ ДАННЫХ
Понятие реляционный (англ. relation — отношение) связано с разработками известного американского специалиста в области систем баз данных, сотрудника фирмы IBM д-ра Е. Кодда (Codd E.F., A Relational Model of Data for Large Shared Data Banks. CACM 13: 6, June 1970), которым впервые был применен термин «реляционная модель данных».
В течение долгого времени реляционный подход рассматривался как удобный формальный аппарат анализа баз данных, не имеющий практических перспектив, так как его реализация требовала слишком больших машинных ресурсов. Только с появлением персональных ЭВМ реляционные и близкие к ним системы стали распространяться, практически не оставив места другим моделям.
Эти модели характеризуются простотой структуры данных, удобным для пользователя табличным представлением и возможностью использования формального аппарата алгебры отношений и реляционного исчисления для обработки данных.
Реляционная модель ориентирована на организацию данных в виде двумерных таблиц. Каждая реляционная таблица представляет собой двумерный массив и обладает следующими свойствами:
- каждый элемент таблицы — один элемент данных;
- повторяющиеся группы отсутствуют;
- все столбцы в таблице однородные, т.е. все элементы в столбце имеют одинаковый тип (числовой, символьный и т.д.) и длину;
- каждый столбец имеет уникальное имя;
- одинаковые строки в таблице отсутствуют;
отношением
реляционной
Отношения представлены в виде таблиц, строки которых соответствуют кортежам или записям, а столбцы — атрибутам отношений, доменам, полям.
простым ключом
внешний ключ
Предложив реляционную модель данных, Э.Ф.Кодд создал и инструмент для удобной работы с отношениями – реляционную алгебру. Каждая операция этой алгебры использует одну или несколько таблиц (отношений) в качестве ее операндов и продуцирует в результате новую таблицу, т.е. позволяет «разрезать» или «склеивать» таблицы.
Некоторые операции реляционной алгебры
Чем же принципиально отличаются реляционные модели от сетевых и иерархических? Вкратце на это можно ответить следующим образом: иерархические и сетевые модели данных — имеют связь по структуре, а реляционные — имеют связь по значению.
Проектирование баз данных традиционно считалось очень трудной задачей. Реляционная технология значительно упрощает эту задачу.
Разделением логического и физического уровней системы она упрощает процесс отображения «уровня реального мира», в структуру, которую система может прямо поддерживать. Поскольку реляционная структура сама по себе концептуально проста, она позволяет реализовывать небольшие и/или простые (и поэтому легкие для создания) базы данных, такие как персональные, сама возможность реализации которых никогда даже бы не рассматривалась в старых более сложных системах.
Теория и дисциплина нормализации может помочь, показывая, что случается, если отношения не структурированы естественным образом.
Реляционная модель данных особенно удобна для использования в базах данных распределенной архитектуры — она позволяет получать доступ к любым информационным элементам, хранящимся в узлах сети ЭВМ. Необходимо обратить особое внимание на высокоуровневый аспект реляционного подхода, который состоит во множественной обработке записей. Благодаря этому значительно возрастает потенциал реляционного подхода, который не может быть достигнут при обработке по одной записи и, прежде всего, это касается оптимизации.
Данная модель позволяет определя
- операции по запоминанию и поиску данных;
- ограничения, с обеспечением целостности данных.
Для увеличения эффективности работы во СУБД реляционного типа приняты ограничения, соответствующие строгой реляционной модели.
записями
Основным преимуществом реляционных СУБД является возможность связывания на основе определенных соотношений файлов БД.
Со структурной точки зрения реляционные модели являются более простыми и однородными, чем иерархические и сетевые. В реляционной модели каждому объекту предметной области соответствует одно или более отношений. При необходимости определить связь между объектами явно, она выражае ся в виде отношения, в котором в качестве атрибутов присутствуют идентификаторы взаимосвязанных объектов. В реляционной модели объекты предметной области и связи между ними представляются одинаковыми информационными конструкциями, существенно упрощая саму модель.
реляционной
- поддерживает структуру данны х;
- по крайней мере операции селекции, проекции и соединения отношений.
смешанными,
СутьреляционнойСУБД можно пояснить на следующем простом примере.
| Файл авторов публикаций БД | ||||
| № п/п | Адрес | Телефон | Число публ. | |
| … | … | … | … | |
| 6 | Купцов | Москва | 635-6078 | 140 |
| 7 | Бухтяк | Томск | 637-2050 | 140 |
| 8 | Терпугов | Томск | 538-584 | 250 |
| Файл публикаций РБД | ||||
| № п/п | Назв. Публикации | Тип публ. | Дата |
Объём в п. л. |
| 6 | Основы … | Статья | 2.95 | 2.5 |
| 7 | Проблема … | Книга | 3.97 | 35 |
| 8 | Теория … | Статья | 6.96 | 3.8 |
| … | … | … | … | |
В некоторой реляционной БД имеются два файла авторов и публикаций, каждый из которых содержит определенное число записей, состоящих из фиксированного числа пол ей (соответственно 4 и 5), представляющих данные по соответствующим элементам предметной области. Можно сказать, что определены два отношения (фaйла), имеющие общий элемент — значения поля № п/п. Операции реляциан ной алгебры могут объ единять два типа записей по этому общему элементу. Например, в результате соединения запись Бухтяк может пред ставится в следующем виде:
- Бухтяк<Томск><637-2050><40><Основ …><статья><2.95><2.5>….
т.е. к сведениям об авторе добавляются сведения обо всех его публикациях, имеющихся в РБД.
На сегодняшний день реляционные базы данных остаются самыми распространенными, благодаря своей простоте и наглядности как в процессе создания так и на пользовательском уровне.
Основным достоинством реляционных баз данных является совместимость с самым популярным языком запросов SQL.
С помощью единственного запроса на этом языке можно соединить несколько таблиц во временную таблицу и вырезать из нее требуемые строки и столбцы (селекция и проекция).
Так как табличная структура реляционной базы данных интуитивно понятна пользователям, то и язык SQL является простым и легким для изучения. Реляционная модель имеет солидный теоретический фундамент, на котором были основаны эволюция и реализация реляционных баз данных. На волне популярности, вызванной успехом реляционной модели, SQL стал основным языком для реляционных баз данных.
Но выявлены и недостатки рассмотренной модели баз данных:
- так как все поля одной таблицы должны содержать постоянное число полей заранее определенных типов, приходится создавать дополнительные таблицы, учитывающие индивидуальные особенности элементов, при помощи внешних ключей. Такой подход сильно усложняет создание сколько-нибудь сложных взаимосвязей в базе данных;
- высокая трудоемкость манипулирования информацией и изменения связей.
7. ИНФОРМАЦИОННО-ЛОГИЧЕСКАЯ
МОДЕЛЬ ДАННЫХ
Проектирование базы данных состоит в построении комплекса взаимосвязанных моделей данных.
Важнейшим этапом проектирования базы данных является разработка информационно-логической (инфологической) модели предметной области, не ориентированной на СУБД. В инфологической модели средствами структур данных в интегрированном виде отражают состав и структуру данных, а также информационные потребности приложение (задач и запросов).
Информационно-логическая модель предметной области отражает предметную область в виде совокупности информационных объектов и их структурных связей.
даталогической
 |
 |
Под понимается модель , отражающая кие взаимосвязи между элементами данных безотносительно их содержания и физической организации. При этом даталогическая модель разрабатывается с учетом конкретной реализации СУБД, также с учетом специфики конкретной предметной области на основе ее инфологической модели.
Инфологическая модель предметной области строится первой. Предварительная инфологическая модель строится еще на пред проектной стадии и затем уточняется на более поздних стадиях проектирования баз данных. Затем на ее основе строятся концептуальная (логическая), внутренняя (физическая) и внешняя модели.
Концептуальный
Внутренний уровень
Внешний уровень
Появление новых или изменение информационных потребностей существующих приложений требуют определения для них корректных внешних моделей, при этом на уровне концептуальной и внутренней модели данных изменений не происходит. Изменения в концептуальной модели, вызванные появлением новых видов данных или изменением и структур, могут затрагивать не все приложения, т.е. обеспечивается определенная независимость программ от данных. Изменения в концептуальной модели должны отражаться и внутренней модели, и при неизменной концептуальной модели возможна самостоятельна модификация внутренней модели БД с целью улучшения ее характеристик (время доступа данным, расхода памяти внешних устройств и др.).
Таким образом, БД реализует принцип относительной независимости логической и физической организации данных.
9. ЗАКЛЮЧЕНИЕ
Пользователями БД являютсячетыре основные категории потребителей ее информации и/или поставщиков информации для нее:
- конечные пользователи,
- программисты и системные аналитики,
- персонал поддержки БД в актуальном состоянии,
- администратор БД.
Хорошо спроектированные СУБД ис ользуют развитые графические интерфейсы и поддерживают системы отчетов, отвечающие специфике пользователейуказанных че тыр ех категорий. Персонал поддержки БД и конечные пользователи могут легко осваивать и использовать СУБД для обеспечения своих потребностей без какой-либо специальной подготовки
Цель моделирования – обеспечение наиболее естественных для человека способов сбора и представления той информации, которую предполагается хранить в создаваемой базе данных.
При проектировании программ выясняются запросы и пожелания клиента и определяется возможный подход к решению задачи. Задача анализируется. На основе этого анализа реализуется конкретная модель в конкретной программной среде. Результаты каждого этапа проектирования используются в качестве исходного материала следующего этапа.
Анализируется текущая организация предприятия, выделяются проблемы для решения, определяются объекты отношения между ними, составляется «эскиз» текущей организации предприятия, разрабатывается модель с учетом конкретных условий ее функционирования.
База данных ориентирована на определенную предметную область и организована на основе некоторого подмножества данных. Возможности баз данных полезны в областях, связанных с долговременным управлением информацией, таких как электронные библиотеки и хранилища данных.
10. СПИСОК
ИСПОЛЬЗУЕМОЙ ЛИТЕРАТУРЫ
[Электронный ресурс]//URL: https://liarte.ru/referat/modeli-i-tipyi-dannyih/
1. А. А Жуков, Л.А Федякина “Система контроля знаний TSTST”, Информатика и образование, 1997 г., №2.
2. В.В. Аладьев, Ю.Я. Хунт, М.Л. Шишаков «Основы информатики», Учебное пособие, М., 1999 г.
3. А.А. Ездов, «Лабораторные работы по физике с использованием компьютерной модели», Информатика и образование, 1996 г., №1.
4. М.Г. Ермаков, Л.Е. Андреева, «Вопросы разработки тестирующих программ», Информатика и образование, 1997г., №3.
5. В.В. Бойко, В.М. Савинков, «Проектирование баз данных информационных систем», М., Финансы и статистика, 1989 г.
6. Д. Цикритизис, Ф. Лоховски, «Модели данных», М., Финансы и статистика, 1985 г.
7. К. Дейт, «Введение в системы баз данных», М., Наука, 1980 г.
8. К. Дейт, «Руководство по реляционной СУБД», М., Финансы и статистика, 1988 г.
9. Д. Мейер, «Теория реляционных баз данных», М., Мир, 1987 г.
