Система баз данных



Введение

 

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

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

По мере развития систем баз данных, менялись принципы организации  данных в них: первоначально данные представлялись на основе иерархической, а в последствии сетевой модели. В конце 1970-х – начале 1980-х годов начали появляться первые реляционные продукты. В настоящее время системы баз данных на основе реляционной модели занимают лидирующее положение, несмотря на заявления многих исследователей о скором переходе к объектно-ориентированным системам. В настоящее время объектно-ориентированные системы, тем не менее, развиваются, хотя темпы их развития и сдерживаются медленным принятием соответствующих стандартов. Кроме того, многие коммерческие реляционные системы приобретают объектно-ориентированные черты. На основании этого, можно предположить, что в будущем объектно-ориентированные системы будут постепенно вытеснять реляционные.

В настоящее время  ведутся исследования в следующих направлениях.

  1. Дедуктивные системы;
  2. Экспертные системы;
  3. Расширяемые системы;
  4. Объектно-ориентированные системы.

 

1. Понятие БД и СУБД

 

Система баз данных – это компьютеризированная система основная задача которой  – хранение информации и предоставление доступа к ней по требованию.

Система баз данных включает в себя:

    1. данные, непосредственно сохраняемые в базе данных;
    2. аппаратное обеспечение;
    3. программное обеспечение;
    4. пользователей:
    5. прикладные программисты;
    6. конечные пользователи;
    7. администраторы баз данных.

 

 

 

 

 

 

Рисунок 1.1 – Система баз данных


1.1 Функции СУБД

 

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

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

Реляционные базы данных представляют  собой набор связанных таблиц и ничего кроме них. Термин «реляционная» указывает на то, что между таблицами базы данных могут быть установлены различные отношения. РСУБД составляют один из крупных сегментов рынка баз данных: они включают все от систем клиент/сервер до настольных систем.

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

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

  • текстовые (для хранения строк размером до 255 символов);
  • числовые (целочисленное, с плавающей точкой и т. п.);
  • memo поля – поля для хранения тестовых фрагментов любого размера;
  • дата/время – поля, в которых могут храниться даты и (или) время в национальном формате;
  • логические – поля для хранения  утверждений типа ДА/НЕТ, ВКЛЮЧЕНО/ВЫКЛЮЧЕНО, ИСТИНА/ЛОЖЬ и т. п.;

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

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

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

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

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

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

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

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

Внешний ключ – это поле (или группа полей) одной таблицы, для которого имеется дублированное значение в другой, связанной таблице. В отличие от первичных ключей, внешние ключи зачастую многократно повторяются при установлении отношения один-к-многим.

Одними из основополагающих в концепции баз данных являются обобщенные категории «данные» и  «модель данных».

Понятие «данные» в концепции  баз данных — это набор конкретных значений, параметров, характеризующих  объект, условие, ситуацию или любые  другие факторы. Данные не обладают определенной структурой, данные становятся информацией  тогда, когда пользователь задает им определенную структуру, то есть осознает их смысловое содержание. Поэтому центральным понятием в области баз данных является понятие модели.

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

Известно три основных модели данных: даталогическая, физическая и инфологическая.

1. Даталогическое проектирование  основано на модели логического уровня.

2. Физическое проектирование  состоит в описании и построении  схем хранения данных для определенной  среды хранения.

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

 

 

2. Разработка проекта

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

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

Программный продукт “База данных Учет обслуживания оргтехники” представляет собой базу данных, разработанную с помощью высокоуровнего языка программирования Delphi. Для обеспечения связи таблиц и целостности данных был выбран бесплатный сервер MySql. Программа позволяет хранить данные о пользователях, оргтехнике, гарантийном и прочих видах обслуживания оргтехники, стоимости ремонта, моделях техники, облегчить этот процесс поможет использование справочников. Также позволяет добавлять новые данные, редактировать и выводить отчеты. Особенным, немаловажным объектом являются отчеты, где формируются данные по различным запросам, как на текущую дату, так и за период. Немаловажным является то, что отчет обладает печатной формой и возможностью сохранять статистические данные в файл.

 

3.Построение моделей данных

3.1 Построение инфологической модели с помощью программы MS Visio

Для построения моделей БД удобно использовать программу MS Visio. При построении модели с помощью Visio нужно запустить программу (Пуск\Программы\Microsoft Office\Microsoft Office Visio). После запуска программы необходимо выбрать тип диаграммы (Choose Drawing Type), для

этого выбираем раздел «Database». Далее из этого раздела выбираем шаблон «Database Model Diagram».

Рисунок 3.1 – Окно Выбор темы диаграммы

 

Теперь необходимо преступить к проектированию. Для задания  сущности, нужно выбрать пиктограмму  «View» на палитре инструментов слева и «перетянуть» ее на рабочий лист с помощью мыши.

 

Рисунок 3.2 – Окно Выбор типа пиктограммы

Рисунок 3.3 – Microsoft Office Visio

 

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

Рисунок 3.4 – Свойства таблиц в Visio

Теперь когда сущности созданы, необходимо задать связи между ними. Для этого нужно использовать инструмент Dynamic Connector.

 

Рисунок 3.5 – Инструмент для установления связей между сущностями

 

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

Рисунок 3.6 – Свойства связи

 

Рисунок 3.7 – Свойства связи

 

Так же необходимо добавить имя для созданной связи, для  этого необходимо совершить на ней  двойной щелчок мышью и ввести имя.

Рисунок 3.8 – Обоснование связи между таблицами

 Рисунок 3.9 – Пример построения инфологической модели данных обслуживания оргтехники

 

Подобное представление  данных инфологической модели можно  изобразить пользуясь другими прикладными пакетами программного обеспечения, например Erwin

Инфологическая модель данных

Рисунок 3.10 -  Вариант построения инфологической модели данных в ERwin

3.2 Даталогическое проектирование баз данных

Разработанный выше пример, является примером концептуальной диаграммы. Это означает, что такая модель не учитывает особенности конкретной СУБД. По данной инфологической модели можно построить даталогическую модель, которая уже будут учитываться такие особенности СУБД, как допустимые типы и наименования полей и таблиц, ограничения целостности и т.п. 

Для задания сущности, нужно выбрать пиктограмму «Entity» на палитре инструментов слева

Рисунок 3.11 – Окно Выбор типа пиктограммы

 

Так как мы создаем  даталогическую модель базы данных, то наименование и свойства сущности, необходимо писать латинскими буквами.

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

Рисунок 3.12 – Датологическая модель БД

 

Датологическая модель данных

Рисунок 3.13 – Пример построения модели данных в ERwin

Реальным средством  моделирования данных является не формальный метод нормализации отношений, а  так называемое семантическое моделирование.

В качестве инструмента семантического моделирования используются различные варианты диаграмм сущность-связь (ER - Entity-Relationship).

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

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

При правильном определении сущностей, полученные таблицы будут сразу находиться в 3НФ. Основное достоинство метода состоит в том, модель строится методом последовательных уточнений первоначальных диаграмм.

 

 

4. Создание таблиц в MySQL

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

Для начала создадим основную таблицу со следующими полями в mySQL:

 

Рисунок.4.1 – Создание таблиц в mySQL

 

Любая CУБД  позволяет вносить данные в такую таблицу, редактировать их, удалять и т. п. Кроме того, вы можете поручить системе отсортировать записи в нужном порядке или произвести выборку в соответствии с запросом.

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

На сегодняшний день СУБД MySQL является одной из самых  известных, надежных и быстрых из всего семейства существующих СУБД. Почему именно она? Одной из причин являются правила ее распространения — за нее не надо платить деньги и распространяется она вместе со своими исходными текстами, другая причина – это то, что MySQL относительно быстрая СУБД.  PostgreSql, например, также распространяется под лицензией *GNU GPL, но она не получила столь широкого распространения. Одна из причин — это заметная медлительность.  Итак, две главные причины популярности MySQL: цена и производительность.

MySQL написан под десятки  видов операционных систем. Это и FreeBSD, OpenBSD, MacOS, OS/2, SunOS, Win9x/00/NT и Linux. Сегодня MySQL особенно распространена на платформах Linux и Windows. Причем на последней встречается гораздо реже.

Принцип работы СУБД MySQL аналогичен принципу работы любой СУБД, использующей SQL (Structured Query Language, язык структурированных запросов) в качестве командного языка для создания/удаления баз данных, таблиц, для пополнения таблиц данными, для осуществления выборки данных.

Целью данной работы является описание конфигурирования, администрирования и программирования СУБД MySQL  и создание программы иллюстрирующей возможности MySQL.

 

4.1 Общее описание, запуск и настройка прав доступа к

базам данных MуSQL.

MySQL, как и любая другая СУБД представляет собой программу-сервер, которая находится в памяти компьютера и обслуживает TCP порт. В случае с MySQL, номером порта будет являться число 3306. А клиентская программа, будь то CGI-приложение на Perl либо программный продукт на C, соединяется с СУБД по этому порту и посылает ему строчки на SQL. Тот в свою очередь их интерпретирует, выполняя необходимые действия, и отсылает результаты запроса обратно клиенту. Таким способом происходит общение сервера баз данных с клиентскими программами.

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

База данных, которую  сервер MуSQL использует для хранения внутренней информации о пользователях, по умолчанию имеет имя mуsql. В этой базе данных определены таблицы для хранения информации пользовательских учетных записей

 

Установка сервера MySQL.

  1. Создать на диске С папку MySQL - С:\ MySQL
  2. Распаковать mysql-5.1.30-win32.zip
  3. Запустить Setup.exe
  4. Выбрать Next

Рисунок 4.2 – Окно установки MySQL

Рисунок 4.3 – Окно установки MySQL

 

5. Выбрать Custom

Рисунок 4.4 – Окно установки MySQL

6.  Change – для того, чтобы указать созданную ранее папку MySQL на диске С.

  1. Показываем путь к созданной директории С:\Mysql

8. Next

Рисунок 4.5 – Окно установки MySQL

9. Install 

Рисунок 4.6 – Окно установки MySQL

12. Finish

Рисунок 4.7 – Окно установки MySQL

13. Next

Рисунок 4.8 – Окно установки MySQL

14. Next

Рисунок 4.9 – Окно установки MySQL

16. Next

Рисунок 4.10 – Окно установки MySQL

17.Next

Рисунок 4.11 – Окно установки MySQL

18. Устанавить CP1251, для поддержки русского языка,

Выбрать Next

Рисунок 4.12 –Окно установки MySQL

14. Вводим пароль root. В нашем случае 123, отмечаем доступ для root с удаленных машин, Next

Рисунок 4.13 – Окно установки MySQL

15. Execute

Рисунок 4.14 – Окно установки MySQL

16. Finish

 

Установка ODBC драйвера к MySQL

  • Распаковать mysql-connector-odbc-3.51.27-win32.zip
  • Запустить Setup.exe

Рисунок 4.15 – Окно установки драйвера ОDBC

  • Next
  • Выбрать Custom, Next

Рисунок 4.16 – Окно установки драйвера ОDBC

  • Install, Finish
  • Далее создать новый источник данных на компьютере и указать используемый драйвер - Пуск\Панель Управления –\Администрирование\ Источники данных (ODBC)\ Системный DSN\ Добавить

Рисунок 4.17 – Окно добавления нового источника данных

 

 Выбрать MySql OBDC 3.51 Driver, готово

Рисунок 4.18 – Окно ввода параметров соединения

  • Имя root, пароль 123, база данных hardware
  • Выбрать вкладку Connect options - Character Set - cp1251,

Рисунок 4.19 – Окно администратора источника данных

  • OK
Для запуска MуSQL-сервера необходимо выполнить файл  mysqld.exe. Сервер запускается как безоконный фоновый процесс. При этом он остается в памяти и обрабатывает запросы от клиентских приложений.

Из меню Пуск-Все программы – mySQL выбираем MySQL Administrator.

В открывшемся приложении в разделе каталоги (catalogs) – создаем новую схему БД и заполняем необходимые таблицы

 

Рисунок 4.20 – Окно схем MySQL Administrator

 

5. Создание приложения для редактирования таблицы

Используя Borland Delphi, можно создать приложения, работающие как с однопользовательскими базами данных (БД), так и с серверными СУБД, такими как Oracle, Sybase, Informix, Interbase, MS SQL Server, DB2, а также с ODBC-источниками. Возможности Delphi, связанные с созданием приложений, использующих базы данных, весьма обширны.

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

Набор данных в Delphi является потомком абстрактного класса TDataSet (абстрактный класс - это класс, от которого можно порождать другие классы, но нельзя создать экземпляр объекта данного класса). Например, классы TQuery, TTable и TStoredProc, содержащиеся на странице палитры компонентов Data Access, - наследники TDBDataSet, который, в свою очередь, является наследником TDataSet. TDataSet содержит абстракции, необходимые для непосредственного управления таблицами или запросами, обеспечивая средства для того, чтобы открыть таблицу или выполнить запрос и перемещаться по строкам

 

Рисунок 5.1 – Использование компанента Main Menu

Добавляем еще одну форму (дочернюю(FS MDI Child))  - это форма для рабочего справочника

Для осуществления связи с таблицами MySQL используется ADOconnection1. А компонент ADOtable осуществляет выборку данных из таблиц MySQL.

Компоненты DBGrid, DBNovigator связываются с ADOtable через Datasource

Компонент DataSource действует  как посредник между компонентами TDataSet (TTable, TQuery, TStoredProc) и компонентами Data Controls - элементами управления, обеспечивающими  представление данных на форме. Компоненты TDataSet управляют связями с библиотекой Borland Database Engine (BDE), а компонент DataSource управляет связями с данными в компонентах Data Controls.

В типичных приложениях  БД компонент DataSource, как правило, связан с одним компоненом TDataSet (TTable или TQuery) и с одним или более компонентами Data Controls (такими, как DBGrid, DBEdit и др.). Связь этого компонента с компонентами TDataSet и DataControls осуществляется с использованием следующих свойств и событий:

  • Cвойство DataSet компонента DataSource идентифицирует имя компонента TDataSet. Можно присвоить значение свойству DataSet на этапе выполнения или с помощью инспектора объектов на этапе проектирования.
  • Cвойство Enabled компонента DataSource активизирует или останавливает взаимосвязь между компонентами TDataSource и Data Controls. Если значение свойства Enabled равно true, то компоненты Data Controls, связанные с TDataSource, воспринимают изменения набора данных. Использование свойства Enabled позволяет временно разъединять визуальные компоненты Data Controls и TDataSource, например, для того, чтобы в случае поиска в таблице с большим количеством записей не отображать на экране пролистывание всей таблицы.
  • Свойство AutoEdit компонента DataSource контролирует, как инициируется редактирование в компонентах Data Controls. Если значение свойства AutoEdit равно true, то режим редактирования начинается непосредственно при получении фокуса компонентом Data Controls, связанным с данным компонентом TDataSet. В противном случае режим редактирования начинается, когда вызывается метод Edit компонента TDataSet, например, после нажатия пользователем кнопки Edit на компоненте DBNavigator. · Событие OnDataChange компонента DataSource наступает, когда происходит изменение значения поля, записи, таблицы, запроса.
  • Cобытие OnUpdateData компонента DataSource наступает, когда пользователь пытается изменить текущую запись в TDataSet. Обработчик этого события следует создавать, когда требуется соблюсти условия ссылочной целостности или ограничения, накладываемые на значения полей изменяемой базы данных.

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

  • Active - указывает, открыта (true) или нет (false) данная таблица.
  • DatabaseName - имя каталога, содержащего искомую таблицу, либо псевдоним (alias) удаленной БД (псевдонимы устанавливаются с помощью утилиты конфигурации BDE, описание которой присутствует во многих источниках, посвященных продуктам Borland, либо с помощью SQL Explorer, вызываемого с помощью пункта меню Database/Explore). Это свойство может быть изменено только в случае, если таблица закрыта (ее свойство Active равно false), например: